.NET Framework - Adobe programming techniques

Asked By Ajgor on 03-Aug-12 12:21 PM

I'd like to ask about Adobe programming techniques :) Does they use any
standard panels/controls, or do their own? F.e. in Adobe Bridge, or Adobe
Premiere... They have fine dockable pannels (much better, than in
DockPanelSuite). How they do it?

Peter Duniho replied to Ajgor on 03-Aug-12 12:46 PM
1) I would not use Adobe as an example for programming techniques. There
are lots of examples of problems with the user experience in Adobe products
that are probably better left not emulated.

2) If Adobe does any programming using C#, I am sure it is very minimal. So
your question really has little if any relevance in this newsgroup.

More to the point, if you want to know how Adobe writes their code, you
should probably ask Adobe. Not that I think there is a high chance of them
revealing much of interest, but at least they are the ones who would know.

Ajgor replied to Peter Duniho on 03-Aug-12 01:50 PM
Uzytkownik "Peter Duniho" napisal w wiadomosci

When installing any of Adobe products, there is sometime question about
instaling the NET Framework, so as I guess, they use any of NET languages.
I Think, it is Visual C++, so as I hope, it is possible to translate it to
C# :) But U are right with that problems..

Heh... Yes :) That is good idea :) But I think, They will not even answer
for that "stupid" questions :)

I only would like to know, do they use a WPF, or standard WinForms, or
Is there a way to recognize it?
Peter Duniho replied to Ajgor on 03-Aug-12 03:32 PM
Adobe has a wide range of products, including Photoshop, Premiere, Acrobat,
Acrobat Reader, the Flash suite, Audition, etc.  I strongly doubt that
_any_ of those products use .NET in any significant way.  It might be used
in an installer or some "dashboard/launcher" style application, but in the
primary code of any those products?  Not very likely at all.

As far as recognizing the use of .NET goes, you can use something like the
SysInternals Process Explorer utility, which will show you lots of details
about running processes, including what DLLs are loaded.  But without
attaching a debugger and/or using other specialized disassembly tools, you
will not get detailed information about how those DLLs are actually being

Note that at least some commercial programs attempt to limit the use of
debuggers, by detecting their presence and disabling features or refusing
to run outright if one's attached.

Finally, there is of course the question of copyright.  The Adobe
implementations of the features you are asking about are almost certainly
protected by copyright.  At best, inspecting Adobe's implementation is
valuable to you as a learning exercise, and frankly I think a much better
learning exercise would be for you to study the _behavior_ of the features,
and figure out how to implement them yourself from scratch.

I think you are also a lot less likely to cross the line between legal and
illegal activities as well.  There is a whole body of case law addressing
the question of how much reverse-engineering and study of someone else's
technology you can do without violating copyright, so you really need a
lawyer to navigate that area.  But in practice it seems to me most people
follow "clean-room" strategies, because otherwise it is very difficult to
prove you did not just lift the technology outright.

Ajgor replied to Peter Duniho on 04-Aug-12 03:28 AM
Oh. No No No... I do not want to spy into their applications, and do any
other illegal job :)
I even do not have their applications, (except Adobe reader :) , but I saw
it my friends work
(a little advertising agency), and then watched some movies on Youtube.
I am only learning C#, and wondering, how do They make their nice GUI's :)
Peter Duniho replied to Ajgor on 04-Aug-12 07:56 PM
I guess the UI in most of their programs are nice-_looking_.  The usability
of those UIs is in the eye of the beholder, I suppose.  I find Adobe
products in general to be hard to navigate.

Anyway, I guess if you are not trying to reverse-engineer their actual
code, than a more useful reply to your original question would be to
suggest that you just focus on learning the graphics APIs in the
programming environments you are working in.  You can create the same
_appearance_ in practically any graphics API, with varying amounts of work.

For .NET, if you know no other graphical API for Windows yet, I would
suggest WPF.  I personally find it a pain in the neck, but I am sure to some
extent that is because I am stuck in WinForms-Land, having had over a decade
of experience with the native Windows API before I even saw .NET  That past
experience was much more useful to me for learning WinForms than it has
been for WPF.

But Microsoft is pushing WPF, and more recently new APIs that are WPF-like.
So unless you have past experience you want to leverage, I think WPF is a
good choice in spite of my own difficulties with it. :)