Tag: Windows

Windows Central: “Before this model, Microsoft had the unified kernel (OneCore), but the OS-level stuff was different across Windows 10 Mobile, Windows 10 PC, Xbox, HoloLens, and Surface Hub. Each one required its own team to maintain. While they all shared the kernel (OneCore) and app layer (UWP) the “middle” of each needed its own engineering team.

With Windows Core OS this model is killed off. The kernel, app layer and now OS-level components are all the same. The one difference will be the shell or the UI. In the Windows Core OS model, these are also referred to as “composers.” For instance, there can be a tablet composer, one for desktop, and one for mobile.”

Back in 2011 I did a bit of speculating about the design of Windows 8 and WinRT. It’s fun to think about overall designs of operating systems and Windows is definitely fun to ponder.

I really love Microsoft’s commitment to making Windows usable by mouse or by touch. I’ve seen plenty of people touching the displays of their Windows based machines and it works just fine. On the desktop it might not be ideal but we’re moving toward a more mobile world, maybe it’s safe to say we’ve already moved to a mobile world? In this world having a touch based device that also has a mouse is ideal. I can dock it at work and use it with my big displays then pack it up and use it at home on the couch as a touch device. This is precisely why I’d love Apple to continue to evolve the iPad into a hybrid that includes a mouse and touch.

I’m a longtime Windows user turned Mac fanatic, but I still think Windows is a great operating system.

Brent Simmons: “What if — and it’s a big if — Microsoft made Swift a peer with C# and provided some good app frameworks?”

When I published What Ifs and Why Nots I hadn’t read Brent’s piece. He’s actually asking the same questions. What would it take to pull Mac developers to Windows? It would take more than Swift, I’m pretty certain. In a Microsoft .Net world where would Swift fit? Would Microsoft just create a version of Swift that works with the .Net garbage collector, or would it be a compiled language? I’d bet on the former given Microsoft’s all-in on .Net and garbage collection.

The bigger questions is Frameworks. Let’s just say Microsoft does a .Net version of Swift. To create a Windows application you’d have to embrace WinRT. You could use your knowledge of Swift, but you’d have to learn a completely new way of writing applications.

Think about all the things Foundation does for you. If you were to move to Windows and Swift on Windows was all .Net based you couldn’t even reuse your non-UI based classes. You could, of course, reimplement your shared classes to use .Net stuff and maintain your interfaces, but you’d have to do a considerable amount of coding to fit on the platform.

Maybe you don’t make Swift a .Net language. Maybe you bring Foundation over to Windows using the Windows API, which is very different from a development standpoint, and not the preferred way to code new apps on Windows. This could also work. You would have a compiled Swift that could natively link to Foundation, which in turn uses Windows API’s to do any platform level stuff. You could then reuse some of your code investment, like those shared non-UI classes and work on creation of a native Windows UI for your application.

Also, of note. Microsoft already has a great set of Frameworks to use, just use them. It would be like coming to the Mac from Windows and saying “Apple needs to provide some good app frameworks.” They already do, you just need to learn to use them to make the best experience for your users. That is the biggest hurdle for any developer.

Learning the new frameworks and a new OS can be quite daunting. When I came to iOS from doing Windows and Linux based UI’s (using Qt mind) I fought with Interface Builder and decided I had to do everything in code because I couldn’t figure it out. Later I made my peace with it. I still think Visual Studio is the better development environment, but Xcode is a very close second, maybe tied, at this point.

I’m kind of a knucklehead. I spent almost 20-years doing native Windows API based applications so I was very comfortable with Visual Studio and that entire ecosystem. If I can learn to write iOS Applications and embrace the tools, then anyone doing Mac or iOS apps could learn to do Windows based stuff today. Just embrace it, don’t try to force your tools into the platform. Now, if you have some code that can easily come over, you might as well use it, but we all know the best apps feel right on the platform. Embrace the platform.

The new Surface Studio is the first bit of Windows based hardware that has excited me this much about the platform in a very long time. I’d love to work on a new design app for Windows, if I could. Maybe even one that works on both platforms; Windows and Mac. Why not? I mean besides time and money, what else does one need to do something so ambitious? 😀

I was inspired by a recent post by Brent Simmons to write about some ancient C++ code I wrote back in the min-90’s. At that time I was just learning to develop Windows applications in C and C++ was just starting to get some traction, not unlike Swift in the Mac and iOS community today.

When you created a Windows application you’d have to write a WindowProc (Windows Procedure) that would process all messages for a particular window. A Window Proc would receive a message and other parameters. You’d switch on the message and the WPARAM and LPARAM parameters would contain other information specific to a particular message. It was well documented, but it was quite ugly.

Believe it or not this is how a lot of your favorite Windows applications were originally written. Giant switch statements that dissected two other values to determine how to respond to different types of messages.

When I started learning C++ I was trying to find a way to create a Window Proc that didn’t have to implement every Windows message in the system, there must be thousands of them. Could you imagine a base C++ class that responded to every Windows API message in the system? I can’t. It would be a real mess to deal with.

It took me quite a while to come up with a way to do it. I happened upon the answer in theC++ FAQ. This would allow me to create a base class that provided one Window Proc that would look in a dispatch table (a map) to see if the Windows Message was handled by the Window in question.

When you implemented a Window Proc class you would derive from a base class and provide it with a message dispatch table (at the top of the above gist.) The dispatch table would direct the base classes Window Proc to call the correct handler for a specific message.

Notice that this Window Proc is a straight C function. That’s how the Windows API operates. It’s a C based API, but it provides a mechanism to attach user provided data to a Window Procedure. That’s how this operates. When the Windows WM_CREATE message is sent it includes a this pointer to derived Window Class, which can be looked up later based on the HWND identifier.

In the gist above the code that calls pWindow->DispatchMessage knows how to look at the dispatch table and direct the message to the appropriate pointer to a method.

The code that knows how to send a message to a particular method is (this->*pHandler)(wParam, lParam). This is dereferencing a pointer to a method. All methods have the same signature, which is consistent with how the Windows API works.

Will Code C++ for FoodBy the way. This code still builds and runs with up to date versions of Visual Studio on Windows 10. A lot of this code was written in 1995 and has been tweaked over time to keep it up to date with changes to the Windows API.

If you’re feeling really brave you’re welcome to grab my crusty old C++ library and build the simple sample application on your Windows box. Please note, the code is provided as is without warranty, expressed or implied.

I got one serious answer and some fun poked at the question, which is fine, but I think it points to a real problem on the Windows Desktop.

Has Microsoft given up on native applications at a time when native on Apple Platforms and Android have never been more popular?

On Apple Platforms we have clear, well defined, native development tools for creating serious desktop applications. Think of apps like Photoshop, or more modern takes on graphics like Sketch, Acorn, Pixelmator, or OmniGraffle. Most of these applications are written in Objective-C against Cocoa (Apple’s Framework for writing applications.) Sure, Photoshop is the old guy in the mix and is built on a custom framework written in C++ that communicates down to Cocoa (and possibly some Carbon API’s?) also worth noting, with the exception of Photoshop, not a single app mentioned above is cross platform (I’m not including Mac to iOS as cross platform, many of the API’s are the same and the act of going from one to the other is much easier than going to a completely different platform.)

All that brings me back to the question of developing native applications in the vein of Visio or Photoshop on the Windows Desktop. I’ve seen plenty of talk about creating Universal Apps, but those seem geared toward a lighter weight style of application, singular purpose apps focused on lightweight tasks, like Twitter or Facebooks clients, not hard core productivity applications that need to perform well and provide their best experience on the Desktop.

We still have Visual Studio, C++, and the Windows API, as a development platform but it feels somewhat abandoned. I know the folks working on the C++ compiler would probably argue against that statement because Microsoft is definitely investing in C++, but what about OS level API’s? That is the level that sort of feels abandoned. We have WinRT today, which seems like it might be part of the story for native desktop development, but do you mix and match that with the Windows API to build a great native application, do you use WinRT alone, or do you just continue to plug away with the Windows API?

It seems that apps built for the modern Metro look should use WinRT? Based on that it seems the old tried and try combination of C++ and the Windows API would still be the best choice for hard core desktop development.

But what about C# and XAML? Maybe those are a good choice for serious desktop development? I’m unclear on that subject. I’ve heard that the Visual Studio IDE was rewritten in C# for Visual Studion 2012, but I don’t know if that’s true or not. If someone reads this post and can point to MS Office, Visual studio, or Photoshop class applications written in C#/.NET I’d love to hear about them. Worth noting is the wonderful toolset by the folks at Xamarin, it makes C#/.NET app development truly cross platform.

Being a long time C++/Windows API guy I still gravitate toward that toolset. Hey, I have a lightweight class library I wrote in 1993-94 that still works today; it builds with Visual Studio 2015 and runs fine on Windows 10, but it could certainly use some refactoring given the state of modern C++. Think C++14.

I’ve been working on a cross platform project recently using Qt, which has me think about portable C++ for Mac, iOS, Windows, and Android. Given C++14 as a starting point for most OS level services; file I/O, threading and synchronization, etc, what would it take to build a modern C++ library that handled native user interface creation and interaction and didn’t feel too constraining on the platform? Remember, most cross platform tools come at a price. They’re always a little behind, they tend to be least common denominator, and can feel non-native. Qt, for instance, doesn’t use native controls on Windows (NOTE: this may not be true today. This was true around 2008, the last time I looked), I find that terribly annoying. I’m sure any Mac, iOS, or Android developer worth their salt would also find it annoying.

A nice new C++ framework for building native OS level user interfaces using modern C++ as a base would be great to see. I really wonder how long it would take to build such a thing?

I happened across some old C++ code I wrote back in 2001. I decided to put it up on GitHub for kicks, might as well put some history up for future generations, right?

I was curious to see if I could build it. The original project was built with Visual Studio 6.0, circa 1998. I have a copy of Visual Studio 2010, so I fired it up pointed it at the original cp.dsw file and was pleasantly surprised it converted. I selected Build All and got a few warnings about some ATL include files I no longer needed, so I removed those. The only other thing that needs correcting are a few warnings related to use of older CRT string copy functions that are not secure. If you’ve upgraded a C or C++ project over the last few years you’ll be familiar with this warning:

warning C4996: '_tcsncpy': This function or variable may be unsafe. Consider using _tcsncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

The code still builds and will execute, but if I were going to use it daily, I’d update it. For now, it’s OK, the code built. Maybe I’ll download a new copy of Visual Studio 2013, get it working with that, and check it in. It would be pretty nifty to create a Mac version by doing an implementation of the HttpIf interface using NSURL and NSURLConnection. This could be a GrilledCheese implementation. Hmmmmmm.

Anywho, once I got a build I hopped out to the command line, and ran it. I was surprised to see, it still works. Amazing.

Disclosure

By day I’m the Development Lead for a small group of folks responsible for the Pelco SDK. This post is not an official Pelco article, just something I wanted to share.

Background

Last August I rejoined Pelco to help design a new object oriented version of the SDK and that’s what we’ve been doing for the last year plus. We’ve released four revisions of the SDK over that time period and are working on our fifth.

Something I’ve wanted to share for a very long time is how simple it is to work with our new Object Model to collect devices and play video. We’ve simplified the entire process. The original version of the SDK evolved from need, as a lot of things do, but over time it becomes more and more difficult to maintain and enhance that code without breaking backward compatibility. In the new Object Model we’ve worked very hard to make it easy and give you the power you need to code new solutions and give us a platform to build on in the future.

I plan on sharing a sample application after a very brief overview of our Object Model. The application, called EnumDevices, is a C++ application. You can find it on GitHub. I’d be happy to create the same application in C#/.Net. If you’re interested get in touch, rob@crabapples.net.

Overview

The Object Model is pretty simple, here are a few objects, just to get us started. You can view the entire list on PDN(it’s a PDF file.)

SystemCollection

System

DeviceCollection

Device

Camera

Display

Stream

Of those we’ll discuss System, DeviceCollection, and Device in the sample. There is some boilerplate code you’ll need to write, but we’ll skip that for now, so we can get on with the sample. Look at main() in the EnumDevices sample, the boilerplate happens prior to calling the EnumDevices function. Something to note. This sample uses version 3.3.1 of the SDK, which introduced an explicit Startup() and Shutdown() function, keep that in mind if you’re using version 3.0 through 3.3, these functions don’t exist in those releases.

EnumDevices C++ Sample

Some things to note about the sample code. It’s only available for Visual Studio 2010. Our SDK only supports Visual Studio 2008 and Visual Studio 2010 for the time being. I have no idea how it will behave in Visual Studio 2012 or Visual Studio 2013.

Ok, on with the code. We’re going to focus on one function in the sample; EnumDevices. This little bit of code will add, or get, a System, get the DeviceCollection and enumerate it. As it does it will print out the Device Friendly Name. That’s it.

PelcoSDK::System

Dissecting the code. I’m sure the first line of code, where we create the System, will have folks asking questions. When we were trying to decide our model for creation and access of Systems we wanted to make it as easy as possible and provide a great deal of power without forcing the user to jump through a lot of hoops. In the end it was decided we’d fashion it after a URI Scheme. Today most people know what a web address looks like.

The interesting portion of that line is "admin:admin@pelcosystem://1.2.3.4:80?alias=Alias". In our scheme “pelcosystem” represents the scheme name, we’ve put the username and password information to the left of the scheme, before the @. Following the :// is the host name, followed by the port, and a query string. We use the query string for arguments, in this example we’re assigning an alias name to the System so we can use that to look it up later, or display it in our user interface.

Something else to note about the use of the scheme in the sample. It serves to do the initial add of the System to the SystemCollection and works to look the System up later, without going to the SystemCollection. Our sample could have also added the System to the SystemCollection by using the Add method directly on the SystemCollection, but it’s not required. That said, the first time you run this code it will be a bit slower than subsequent runs. The first time through the System and all its devices will be added to a local device cache so the next time you startup will be much quicker.

PelcoSDK::DeviceCollection

The second line of code is pretty straight forward. After we’ve created, or retrieved, a System we’d like to get the DeviceCollection so we can do something interesting. Maybe we’d like to populate a tree control with a list of devices, or just dump out device information to a simple console application, like this sample.

PelcoSDK::DeviceCollection devices(system.GetDeviceCollection());

There’s not a lot to talk about here. We’re constructing a C++ object of type PelcoSDK::DeviceCollection using the results of a call to system.GetDeviceCollection(). Now we have a DeviceCollection Object we can enumerate.

All of the collection classes in the SDK implement an interface called IEnumerator, it’s a template class that exposes three methods; Current, MoveNext, and Reset. These methods make it really easy to iterate all collections in the SDK with a simple while loop.

After getting our collection it should be in a “reset” state, but the first line of code above shows how to reset the internal iterator back to the beginning of the collection. Notice the while loop checks the result of the devices.MoveNext(). The MoveNext method will move the iterator to the next item in the collection and returns a boolean value, true if it has a next device, false if it doesn’t. Once there are no longer devices in the collection we’ll break out of the loop.

If we do have a device in the collection you can retrieve it by asking the DeviceCollection for its Current() object. Since IEnumerator is a C++ template the type of object returned is a PelcoSDK::Device. You can read more about the Device Object on the Pelco Developer Network(PDN).

EOL

Hopefully this sheds a bit of light on the direction of the Pelco SDK. We’re off to a nice start, but we have a long way to go, and we’d love to hear back from developers and partners. Please, reach out. Let us know how we’re doing, where we need to improve, and share your stories.

I’m a Mac

I’ve been a Mac for a few years now. When I was working at Pelco a few years back I had a 17″ MacBook Pro and I loved it. We bought our daughters Macs when they graduated from high school and I bought my lovely wife a Mac. We have more than a few iPod’s laying around the house and four iPhones between us. We’re definitely an Apple loving family.

I was finally able to venture out on my own in May, 2012. My primary goal was to find enough freelance work to allow me to work on my own software from time to time. I’d love to ship some iOS and Mac software this year, or early next year. So far things have been great. I’m just rolling off a great project and trying to wrap up another, both iOS. But, being a freelancer is difficult. Work is work, right?

To Windows, or not to Windows?

Most of my 20 plus hears has been spent writing software for Windows, so it’s something I know, and I’m comfortable writing software on that platform. I’ve been in discussions with a company to work on some Windows based software, so I may need a PC once again.

I have a decent MacBook Pro so I wonder if VMWare would do the trick, but the software I’d be working on requires hardware accelerated graphics. Have the VM folks solved that problem? Will Direct3D work? I don’t know the answer to that. These are questions I need to solve so I can decide if spending the cash, and carrying around two laptops, is worth it.

PC Laptops

On Saturday I walked into our local Best Buy to see if I could find a decent 15″ laptop for under $1000. All the laptops were under $1000! That was a big surprise. The thing I quickly discovered is I don’t pay attention to hardware any longer. Since I became a Mac user our choices are limited to a few very high end pieces of hardware, so all you have to decide is how much RAM you’d like and how big the hard drive should be. In the PC laptop world is wild and varied. The one thing I did notice is every laptop I looked at had about 4GB of RAM. That would need to be bumped right away to 8GB and I figure I’d need at least a 500GB drive, but what processor should I get? It’s not like I’m going to use this laptop for anything but coding on Windows.

So, the big question. What sub $1000 laptop is decent enough to install Windows 7/8 and run Visual Studio? It doesn’t have to be the best ever, just good enough.

I find it interesting how deep we tend to go as developers when we’re building on top of other code. I’ve been debugging a memory leak in our app and this is part of a call stack for a potential culprit.

Kevin Hoctor: “The irony is that I’m the one always preaching to others that they need to be passionate about what they do. Don’t settle for a paycheck. Don’t work at a place that makes you want to rush home and down a bottle of vodka to balance out the day. Yet, here I am doing exactly what I’ve told my kids not to do.”

Kevin made the transition from frustrated Windows developer to Indie Mac developer and is still going strong. About six months after the above post Kevin shipped Debt Quencher 1.0. I don’t think he’s looked back.

It’s true. Today is my last day with LEVEL Studios. It’s hard to say goodbye to a place like this, especially when you do love her and her people. It’s been a fun year, but it’s time for me to move on.

Why?

That’s the hard part to explain, because I really do love this company. It’s full of smart, energetic, people. It has a great company culture and fantastic leadership. The “problem” falls squarely with me.

Anyone who knows me knows how much I love the native client experience. I’ve had the honor to work with a team that created a new segment in Windows drawing applications and I’ve worked on native iOS applications and I LOVE that experience. I think User Experience, or UX, is so important and I believe the best way to provide that important experience is through native API’s provided by the platform vendor. So, yes, I’m going back to writing desktop software. No, it’s not on the Mac, or iOS, even though I’d love to do that. I’m going back to writing Windows software. That’s right, back to C++ and Windows! I can see my fellow LEVEL’ites rolling their eyes. That’s ok, I likes me some native clients. It’s in my blood.

Where?

Where is a great question. We’re staying in San Luis Obispo, we don’t plan on leaving this place. I’m going to work for a company called CygNet. They’re a product company. From the CygNet website.

I’ll be working on products used to collect and analyze data from Oil and Gas Pipelines, and I get to work on UI again! Yes, I’m pretty stoked about it!

On the LEVEL

LEVEL is a definite powerhouse when it comes to the web. In fact I’d encourage young up-and-coming web developers or designers to consider LEVEL as a place to start your career. You’ll learn loads. LEVEL is chock full of great web developers, not to mention fantastic designers.

Oh, yeah, and there’s this great group of folks, they keep in a dark room, that develop great, high performance, highly scalable, web services. One of our web services is serving near four million users worldwide, and growing every day. Yes, LEVEL can build these things. Shhhhhh, keep that under your hat, it’s a secret!

Would I work here again? Absolutely. That’s what made this decision so tough.