These objects - instances of classes such as wxPen, wxBrush, wxBitmap (but not wxColour) - are now implemented with reference-counting. This makes assignment a very cheap operation, and also means that management of the resource is largely automatic. You now pass references to objects to functions such as wxDC::SetPen, not pointers, so you will need to dereference your pointers. The device context does not store a copy of the pen itself, but takes a copy of it (via reference counting), and the object's data gets freed up when the reference count goes to zero. The application does not have to worry so much about who the object belongs to: it can pass the reference, then destroy the object without leaving a dangling pointer inside the device context.
For the purposes of code migration, you can use the old style of object management - maintaining pointers to GDI objects, and using the FindOrCreate... functions. However, it is preferable to keep this explicit management to a minimum, instead creating objects on the fly as needed, on the stack, unless this causes too much of an overhead in your application.
At a minimum, you will have to make sure that calls to SetPen, SetBrush etc. work. Also, where you pass NULL to these functions, you will need to use an identifier such as wxNullPen or wxNullBrush.