Moving from Delphi 7 to Delphi 2007

Is there any compelling reason to move (quite a large project) from 
Delphi 7 to Delphi 2007?

Specifically, is there better Vista/Win7/Win8 integration provided by 
Delphi 2007? (In the project I am already using a custom manifest file 
for Vista/Win7 etc.. and not the std XPMan component)

Does 2007 add any new bugs to the scene?

Thanks
Rael
0
Rael
12/11/2012 8:11:23 PM
embarcadero.delphi.general 4258 articles. 0 followers. Follow

23 Replies
1579 Views

Similar Articles

[PageSpeed] 27

Rael wrote:

> Is there any compelling reason to move (quite a large project) from
> Delphi 7 to Delphi 2007?

If you are going to upgrade, why not upgrade to something newer?

> In the project I am already using a custom manifest file
> for Vista/Win7 etc.. and not the std XPMan component)

The XPMan component is obsolete.  The VCL has built-in theming support now, 
so you do not need to provide a custom manifest unless you need UAC/UIPI 
support.  XE2 adds a new option to use custom manifests.

--
Remy Lebeau (TeamB)
0
Remy
12/11/2012 8:55:28 PM
On 2012/12/11 10:55 PM, Remy Lebeau (TeamB) wrote:
> Rael wrote:
>
>> Is there any compelling reason to move (quite a large project) from
>> Delphi 7 to Delphi 2007?
>
> If you are going to upgrade, why not upgrade to something newer?

Well at this point it will be a cost in terms of time and updating 3rd 
party components to upgrade to newer unicode versions.

So that is why I am looking at if there is any advantage - perhaps 
better Vista/Win7 integration - in moving from D7 to D2007.

-Rael
0
Rael
12/12/2012 4:29:20 PM
> {quote:title=Rael Bauer wrote:}{quote}
> Is there any compelling reason to move (quite a large project) from 
> Delphi 7 to Delphi 2007?
> 
> Specifically, is there better Vista/Win7/Win8 integration provided by 
> Delphi 2007? (In the project I am already using a custom manifest file 
> for Vista/Win7 etc.. and not the std XPMan component)
> 
> Does 2007 add any new bugs to the scene?

D2007 was a nice release - very stable, and we happily used it (well, RAD Studio 2007) for several years.  I'm sure it has its own bugs, every release does, but in general it was great.

From memory, D2007 had basic Vista support (for example, the Application property MainFormOnTaskBar) but no special Windows 7 or 8 functionality, since those version of Windows weren't released back then.

On the other hand, you're upgrading from something ten years old to something five years old.  *Why?!*  (I only just resisted putting that in all capitals.) Why not upgrade to XE3 and get all the benefits of everything that's been added and fixed since?  You will need to handle the Unicode upgrade, but you'll have to do that anyway and the latest version is an awful lots better than D2007, which is itself I agree an awful lot better than D7.

You can find a list of everything new in each version of Delphi here: http://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre .  Skip the answerer's summary below the links - I think they missed a lot out.  Follow the links themselves to see what's been added.

I suppose what I'm saying is: sure, go to 2007, it's a decent upgrade.  But it's not nearly as good as you could do.

Cheers,

David
0
David
12/12/2012 4:45:01 PM
Rael Bauer wrote:

> Well at this point it will be a cost in terms of time and updating
> 3rd party components to upgrade to newer unicode versions.

You are aware, I hope, that you will need D2007 versions of the
3rd-party components you use in this project? Unless you have them
already for other projects done in D2007 you will have update costs
here as well.

-- 
Peter Below (TeamB)
0
Peter
12/12/2012 5:22:58 PM
> If you are going to upgrade, why not upgrade to something newer?

hehe, because in something newer you change all the DNA by replacing
8 bits string by 16 bits strings :) you can not believe how much are
still on D2007 because of this ! it's sad :(
0
loki
12/12/2012 7:09:06 PM
On 2012/12/12 07:22 PM, Peter Below wrote:
> Rael Bauer wrote:
>
>> Well at this point it will be a cost in terms of time and updating
>> 3rd party components to upgrade to newer unicode versions.
>
> You are aware, I hope, that you will need D2007 versions of the
> 3rd-party components you use in this project? Unless you have them
> already for other projects done in D2007 you will have update costs
> here as well.
>

My impression is that source code would not need to be modified. Only 
new defines (usually in .inc file) might need to be added for 2007, and 
a 2007 package.

Is this incorrect?
0
Rael
12/13/2012 12:27:38 AM
Rael wrote:

> My impression is that source code would not need to be modified.
> Only new defines (usually in .inc file) might need to be added for
> 2007, and a 2007 package.

And who do you think uses the defines?  The compiler.  The package source 
code would have to be recompiled in D2007 in order to recognze the new defines. 
 Packages are version-specific, you cannot use a package that was compiled 
in one compiler version with another compiler version (except for one specific 
situation - D2006 -> D2007, as D2007 was a non-breaking release that was 
binary-compatible with D2006 only).  So every component and every package 
that your migrated app uses must have D2007-specific binaries for it to use. 
 If you are using third-party packages, that means either obtaining D2007-compatible 
binaries from the vendors, or recompiling the source code yourself if you 
have it.  So if you are going to go through all of that trouble anyway, then 
you should consider skipping D2007 and jumping to a modern version (I would 
recommend at least XE2, if not XE3 yet).  The Unicode support has been in 
place for 5 major releases now and is stable.  Depending on what your code 
is actually doing, migrating to Unicode may be as simple as a recompile with 
no chanes, or it may require some code review.  But the effort will be worth 
it overall, and should not take very long (most users have successfully migrated 
their projects to Unicode within a few minutes/hours, if not a few days at 
most).

--
Remy Lebeau (TeamB)
0
Remy
12/13/2012 12:50:24 AM
Rael wrote:

> My impression is that source code would not need to be modified.
> Only new defines (usually in .inc file) might need to be added for
> 2007, and a 2007 package.

And who do you think uses the defines?  The compiler.  The package source 
code would have to be recompiled in D2007 in order to recognze the new defines. 
 Packages are version-specific, you cannot use a package that was compiled 
in one compiler version with another compiler version (except for one specific 
situation - D2006 -> D2007, as D2007 was a non-breaking release that was 
binary-compatible with D2006 only).  So every component and every package 
that your migrated app uses must have D2007-specific binaries for it to use. 
 If you are using third-party packages, that means either obtaining D2007-compatible 
binaries from the vendors, or recompiling the source code yourself if you 
have it.  So if you are going to go through all of that trouble anyway, then 
you should consider skipping D2007 and jumping to a modern version (I would 
recommend at least XE2, if not XE3 yet).  The Unicode support has been in 
place for 5 major releases now and is stable.  Depending on what your code 
is actually doing, migrating to Unicode may be as simple as a recompile with 
no chanes, or it may require some code review.  But the effort will be worth 
it overall, and should not take very long (most users have successfully migrated 
their projects to Unicode within a few minutes/hours, if not a few days at 
most).

--
Remy Lebeau (TeamB)
0
Remy
12/13/2012 1:01:34 AM
Rael


Disclaimer: I'm still on D2006 and liable to stay there

I've seen the slightly different question "should I upgrade to Xn" asked a number of times. There seem to be two items generally quoted as the reason - Unicode, Generics. Unless you need these I'd suggest ignoring the people suggesting making the major jump. I know there are a slew of additional functions but unless you want to spend a lot of time finding them and getting used to them since you're not already using them you probably won't miss having them <g>.


I moved from D6 to D2006 and since for most of my 3rd party components I have the source it was a simple recompile (adding in new IFDEFS or simply removing all the conditional defines in some cases).

You certainly won't get any Vista or later features, you may have to make some alterations for those systems (eg not writing into the ProgramFiles folder). What you will have to do is get used to the different layout in the IDE. That took me a while but I hate going back to D6 now.

Roy Lambert
0
Roy
12/13/2012 10:04:14 AM
Roy wrote:

> I've seen the slightly different question "should I upgrade to Xn"
> asked a number of times. There seem to be two items generally
> quoted as the reason - Unicode, Generics.

And support for newer OS APIs.

> You certainly won't get any Vista or later features, you may have to
> make some alterations for those systems (eg not writing into the
> ProgramFiles folder).

It is more involved with that, if you want to take advantage of newer OS 
features.  If you don't upgrade, then you have to declare newer API functions/types 
manually, do dynamic DLL loading when appropriate if you need to maintain 
backwards compatibility with oolder OS versions, etc.  Depending on the features 
you want to use, this can be a simple effort or a hugh effort.  I myself 
still write apps in BCB 6, but they support OS versions up to Win7, including 
handling UAC, Taskbar enhancements, new dialogs, etc.  Some of that stuff 
is not trivial to backport to older IDEs (TApplication.MainFormOnTaskbar, 
for example).

--
Remy Lebeau (TeamB)
0
Remy
12/13/2012 4:58:46 PM
Remy


>It is more involved with that, if you want to take advantage of newer OS
>features. If you don't upgrade, then you have to declare newer API functions/types
>manually, do dynamic DLL loading when appropriate if you need to maintain
>backwards compatibility with oolder OS versions, etc. Depending on the features
>you want to use, this can be a simple effort or a hugh effort. I myself
>still write apps in BCB 6, but they support OS versions up to Win7, including
>handling UAC, Taskbar enhancements, new dialogs, etc. Some of that stuff
>is not trivial to backport to older IDEs (TApplication.MainFormOnTaskbar,
>for example).

On the basis the OP asked for features supporting the newer versions of Windows that is a very valid point.

Personally I'm still trying to write good apps with decent functionality that look fairly good rather than adopt the latest Microsoft eyecandy or confuse a user system <vbg>

Roy Lambert

ps Having seen Windows 8 I don't think anyone should support it - including Microsoft!!!!
0
Roy
12/13/2012 6:50:03 PM
On Wed, 12 Dec 2012 16:50:24 -0800, Remy Lebeau (TeamB) <no.spam@no.spam.com> wrote:

>have it.  So if you are going to go through all of that trouble anyway, then 
>you should consider skipping D2007 and jumping to a modern version (I would 
>recommend at least XE2, if not XE3 yet).  The Unicode support has been in 
>place for 5 major releases now and is stable.  Depending on what your code 
>is actually doing, migrating to Unicode may be as simple as a recompile with 
>no chanes, or it may require some code review.  But the effort will be worth 
>it overall, and should not take very long (most users have successfully migrated 
>their projects to Unicode within a few minutes/hours, if not a few days at 
>most).

you only forgot to mention that one can expect slowdowns varying from marginal to significant after porting to unicode version

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
12/14/2012 6:11:45 AM
Vladimir wrote:

> you only forgot to mention that one can expect slowdowns varying
> from marginal to significant after porting to unicode version

Such as?

--
Remy Lebeau (TeamB)
0
Remy
12/14/2012 5:34:04 PM
On 12/13/12 1:50 PM, Roy Lambert wrote:
> ps Having seen Windows 8 I don't think anyone should support it - including Microsoft!!!!
>
LOL! +1
0
Mike
12/14/2012 9:00:53 PM
On Fri, 14 Dec 2012 09:34:04 -0800, Remy Lebeau (TeamB) <no.spam@no.spam.com> wrote:

>> you only forgot to mention that one can expect slowdowns varying
>> from marginal to significant after porting to unicode version
>
>Such as?

not sure what your question really means. I tried to remind that unicode support isn't free and usually pure ansi versions tend to work
faster. some parts of libs/apps can work up to say ~10 times slower with unicode strings

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
12/17/2012 6:44:13 AM
Vladimir wrote:

> not sure what your question really means.

I am asking why you think using Unicode can lead to significantly slower 
code.

> I tried to remind that unicode support isn't free and usually pure ansi
> versions tend to work faster.

In what way?

> some parts of libs/apps can work up to say ~10 times slower
> with unicode strings

Can you provide an example?

--
Remy Lebeau (TeamB)
0
Remy
12/17/2012 6:07:29 PM
Remy Lebeau (TeamB) wrote:

> > not sure what your question really means.
> 
> I am asking why you think using Unicode can lead to significantly
> slower code.

If the hypothetical app is extensively using indexed access to (or
adding/deleting portions from) strings, then, yes, unicodifying it can
result in significantly slower runtimes.
0
Adem
12/17/2012 7:55:04 PM
Adem wrote:

> If the hypothetical app is extensively using indexed access to (or
> adding/deleting portions from) strings, then, yes, unicodifying it can
> result in significantly slower runtimes.

Again, can you provide an example?  Indexing a UnicodeString, appending a 
string to a UnicodeString, extracting a substring from a UnicodeString, deleting 
a substring from a UnicodeString - they are implemented the same as their 
AnsiString counterparts.  The only difference is the memory usage is doubled, 
that's all.  That is hardly grounds for a "significant" speed loss by itself, 
especially on modern computers.

--
Remy Lebeau (TeamB)
0
Remy
12/17/2012 8:05:51 PM
Remy Lebeau (TeamB) wrote:

> Adem wrote:
> 
> > If the hypothetical app is extensively using indexed access to (or
> > adding/deleting portions from) strings, then, yes, unicodifying it
> > can result in significantly slower runtimes.
> 
> Again, can you provide an example?  Indexing a UnicodeString,
> appending a string to a UnicodeString, extracting a substring from a
> UnicodeString, deleting a substring from a UnicodeString - they are
> implemented the same as their AnsiString counterparts.  The only
> difference is the memory usage is doubled, that's all.  That is
> hardly grounds for a "significant" speed loss by itself, especially
> on modern computers.

No, no; I am not referring to memory doubling. If anything, my
complaint is that it's not extended enough --I'd have liked it a lot
more if they quadrupled it to 4-byte size.

Anyway, returning to speed issue: Well, if we consider Unicode as BMP
(2-byte codepoints), yes, there's going to be no significant speed loss.

But, if we move beyond BMP, then we have to deal with combining chars,
surrogate pairs etc.; or when we're working with UTF8 --i.e variable
byte size per codepoint.

In these cases, you can't simply index-access; you have to introduce
extra intelligence; and that can cause speed loss --how significant
that will be dependent on how often you have to do that.

But, I grant you this: If your code deals only with ANSI/ASCI/BMP, you
really do not have to worry about speed.

[BTW, I am sorry for not giving you a snippet --which I don't think you
need one, anyway--; the secondary reason for is that my XE setup seems
to be screwed ATM.]
0
Adem
12/17/2012 8:28:29 PM
Hello Adem,

> Anyway, returning to speed issue: Well, if we consider Unicode as BMP
> (2-byte codepoints), yes, there's going to be no significant speed
> loss.
>
> But, if we move beyond BMP, then we have to deal with combining chars,
> surrogate pairs etc.; or when we're working with UTF8 --i.e variable
> byte size per codepoint.

AnsiString has the same issues when dealing with MBCS charsets.  Not all 
Ansi charsets are fixed-length, any more than Unicode encodings are.  In 
UTF-8, some codepoints are single-codeunit values.  In UTF-16, most codepoints 
are single-codeunit values.  But when dealing with codepoints that must use 
multiple codeunits, AnsiString and Unicode have the same variable-length 
complexity.  If anything, some Ansi charsets, especially those that deal 
in RTL encoding, are more complex than Unicode encodings.  As for combining 
charcters, they deal primarily with display and normalization, representation 
inside of a Unicode string is not as much an issue, they are either surrogated 
or they are not.

> In these cases, you can't simply index-access

You can't always do that with AnsiString, either.  That is why API functions 
like CharNext() and CharPrev() exist, even for Ansi strings.  You can index 
directly to a specific codeunit, but if you need to do processing on codepoints 
instead, then you have to process and decode the codeunits first to know 
where the codepoints are located.  AnsiString and UnicodeString are the same 
in that regard.

--
Remy Lebeau (TeamB)
0
Remy
12/17/2012 8:53:29 PM
Remy Lebeau (TeamB) wrote:

> > But, if we move beyond BMP, then we have to deal with combining
> > chars, surrogate pairs etc.; or when we're working with UTF8 --i.e
> > variable byte size per codepoint.
> 
> AnsiString has the same issues when dealing with MBCS charsets.

The moment you mentioned MBCS charsets, made me feel like someone who's
suddenly moved from the telegraph era to smartphones --simple reason is
I never had to deal with them then.

So, yes, you're right, of course; it's my selective memory generalizing
from my personal point of reference of my own vaguely remebered
personal past when everything was more simple and harder to comprehend.
0
Adem
12/17/2012 9:04:33 PM
Adem wrote:

> The moment you mentioned MBCS charsets, made me feel like someone
> who's suddenly moved from the telegraph era to smartphones --simple
> reason is I never had to deal with them then.

Developers who don't deal with internationalization tend to not deal with 
MBCS (or DBCS), which are the alternatives for handling multi-byte languages, 
like Chinese and Japanese, when not using Unicode.

--
Remy Lebeau (TeamB)
0
Remy
12/17/2012 9:19:15 PM
On Mon, 17 Dec 2012 10:07:29 -0800, Remy Lebeau (TeamB) <no.spam@no.spam.com> wrote:

>I am asking why you think using Unicode can lead to significantly slower 
>code.

not "can", it actually does in some cases

>Can you provide an example?

sure, for example devex libs in some circumstances display unicode text ~ 10 times slower than ansi text

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
12/18/2012 6:09:14 AM
Reply:

Similar Artilces:

Delphi 2007 to Delphi 7
I've written a class in Delphi 2007 that is not supported in Delphi 7. What would be the best way to achive what I've done in Delphi 2007 in Delphi 7? Thanks, Tom type BondConstants = class { Bond Types } type BondType = record const TREASURY = 3; AGENCY = 0; CORP = 1; MUNI = 2; SBA = 5; MBS = 4; CMO = 6; end; { Day Count Methods } type DayCount = record const ACTUAL_360 = 2; ACTUAL_365 = 1; ACTUAL_ACTUAL = 1; d30_360 = 0; ...

Delphi 2007 RTL in Delphi 7
I read somewhere that it is possible to use Delphi 2007's (or for that matter Delphi 2006's) RTL in Delphi 7 by just recompiling the source of RTL. Is this really possible? What are the benefits that we can derive using a higher version's RTL? TIA Yogi Yang Yogi Yang wrote: > I read somewhere that it is possible to use Delphi 2007's (or for > that matter Delphi 2006's) RTL in Delphi 7 by just recompiling the > source of RTL. If it actually compiles in Delphi 7, I guess it would be possible. OTOH, if one has Delphi 2007 already, I don't s...

Delphi 4 to Delphi 2007
Hello, I will have to port a D4 application (with source) to D2007. what kind of problem could I face ? I will have to go to customer site tommorow to analyse its source code to quote the work, what should I care of to hestimate the porting time ? Thanks John Terry wrote: > Hello, > I will have to port a D4 application (with source) to D2007. > what kind of problem could I face ? > I will have to go to customer site tommorow to analyse its source code > to quote the work, what should I care of to hestimate the porting time ? You can probably do it by just changi...

Delphi 7 to Delphi XE
Have been using Delphi 7 for many moons ( have got later versions but never upgraded to ) My first problem is: Component Palette. in XE it is a small toolbar docked in top right in Delphi 7 it gives a large view of all the components. I am struggling to be able to cope/access my components.in Delphi XE. Can I make the component pallette tool bar the same size as Delphi 7, or is there a fast way to view/choose all available components in XE, that I have not spotted yet? Kind Regards, Robert. Hi, What I know is that in Delphi 2010 and XE you can choose between t...

Delphi 7 to Delphi XE2
Hi, Still using that old workhorse, Delphi7, but am going to the conference in London hosted by Embarcadero on Delphi XE2. Although I would like to "move with the times" and am keen to get the UNICODE and 64-bit support offered by the latest IDEs, I confess to being more than a little scared about all the UNICODE/String/AnsiString and 32/64 bit issues I'm probably going to fall over. Anyone recently upgraded from Delphi7 to one of the latest Delphi IDEs? Thanks, Alain On 03/02/2012 08:55, Alain Dekker wrote: > Still using that old workhorse, Delphi7, but...

MOVED: Use Delphi XE TLB importer in Delphi 2007?
....to the ActiveX group: https://forums.embarcadero.com/thread.jspa?threadID=47170 -- Craig Stuntz · Vertex Systems Corp. · Columbus, OH Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/ ...

DBExpress terrible performance when migrating from Delphi 7 to Delphi 2007
Hi, When I'm migrating my project from Delphi 7 to Delphi 2007, I found that the speed slow down 3-4 times. I've started to investigate what is the reason of that and I've found that the problem is in the TSQLDataset component. So I make a simple example of an application that run one of my problem queries that fetches about 30000 rows and the result was amazing d7: 1500ms, d2007: 13500ms 8 times slower !!!! Here are some perameters of the TSQLConnection Delphi 7: object SQLConn: TSQLConnection ConnectionName = 'OracleConnection' DriverName = '...

Delphi and Delphi for .Net
It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only. Your information is great appreciated, Inung On 2011-06-21 18:20:17 +0100, Inung Huang said: > It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. > I would like to know is it true all .Net application is slower than > Win32 native applicaiton or it is Delphi for .Net only. If you are only running the code in the application once then, yes, yo...

Delphi 2007 to Delphi 2009 Conversion
CharArrayPtr = ^CharArray; CharArray = array[0..MaxInt-1] of Char; How to convert to Delphi 2009? Bill Bill Miller wrote: > CharArrayPtr = ^CharArray; > CharArray = array[0..MaxInt-1] of Char; > > How to convert to Delphi 2009? > > Bill it depends heavelly on how it is used fearther down in your project and what you want to convert it to. I you want to simple convert the declarations ignoring UNicode altogether then the only think you have to change is the CharArray declaratin from a Char to an AnsiChar eg CharArrayPtr = ^CharArray; CharArray =...

Delphi 7 to Delphi 2009 conversion
Hello group, What do I need to do to comile the following code in D2009. Compiler error after the Else E2010: Incompatible Types 'AnsiChar' and 'Char' if isUnicode then SearchHandle := FindFirstFilew( PWideChar( fn ), FindDataW ) else SearchHandle := FindFirstFile( PAnsiChar( Ansistring( fn ) ), FindDataA ); <<<<<compiler error in the above line >>>>>>>>>>> Regards, Bryan > What do I need to do to comile the following code in D2009. > Compiler error after the Else > E2010: Incompati...

is there a Delphi 2007
Would be nice to have a bundle of the latest Delphi packages. Gilbert Padilla wrote: > Would be nice to have a bundle of the latest Delphi packages. > I expect Delphi 2007 will only be on sale until the full RAD Studio 2009 edition is published, including Delphi 2009.net. W ...

Delphi 2010 w Delphi 2007
I have D2007 installed on my laptop (XP sp3 running on dual core Athlon). Can I install D2010 on this machine without it affecting D2007? Will D2010 affect D2007 in any way? Thanks, Randall Carpenter > {quote:title=Randall Carpenter wrote:}{quote} > I have D2007 installed on my laptop (XP sp3 running on dual core Athlon). > Can I install D2010 on this machine without it affecting D2007? Will D2010 > affect D2007 in any way? Won't hurt a thing. I have D7, RAD Studio 2007, RAD Studio 2009, and RAD Studio 2010 all on my desktop system and they coexist fine. Jus...

Migrate from Delphi 2007 to Delphi 2010
Hi All, Thanks in advance for your help. Below is my query, Currently I am using Delphi 2007 and i want to migrate to Delphi 2010. 1. What all things i need to take care while doing this? 2. What all third party components will get impacted? 3. Any known issues in Delphi 2010 which might impact the cause? 4. Any changes in database operation required as i am using Oracle? Hope I have post this query under correct category. If not sorry for the trouble and could you please suggest me the correct category for this? Looking forward for your response. Have a great day. Th...

Migrating from Delphi 7 to Delphi XE3
Hello, Its time to leave the old Delphi 7 and move to the new (but not the latest) XE3. I was wondering if there is a good book or reference to learn all new things XE3 added. Any suggestions? On 5/3/2013 10:17 PM, George Karatsiolis wrote: > Hello, Its time to leave the old Delphi 7 and move to the new (but not the latest) XE3. > I was wondering if there is a good book or reference to learn all new things XE3 added. Try this one for starters: http://tinyurl.com/cgsu243 Aside from that you really need to evaluate your application. XE3 is Unicode for example.... So her...

Web resources about - Moving from Delphi 7 to Delphi 2007 - embarcadero.delphi.general

Moving Picture Institute - Wikipedia, the free encyclopedia
The Moving Picture Institute ( MPI ) is an American non-profit organization and film production company founded in 2005 by human rights advocate ...

Facebook’s Fitness Apps Keep Users Moving With The Help Of Open Graph
The joy of working out with a Facebook-connected application is that even if you’re not jogging or cycling with someone in person, you can have ...

The moving images of Andy Warhol revealed in National Gallery of Victoria exhibition
Even now, after 20 years of immersion, research and exploration, Warhol expert Greg Pierce believes there are still many things left for him ...

Ian Macfarlane blocked from moving to Nationals by LNP executive
Federal MP Ian Macfarlane is blocked from moving from the Liberals to the Nationals partyroom.

Facebook Moving Photo Syncing to Moments App Jan. 10
... images will move to its Moments application. Clicking on the notification brings users to this page , which reads: Photo syncing is moving ...

NASA official warns private sector: We’re moving on from low-Earth orbit
... thrive in the space around Earth, it is not the agency’s top priority to ensure that happens. Gerstenmaier said NASA is committed to moving ...

Report offers more evidence Apple is moving to OLED iPhone displays
iPhone fans will have to wait until 2018 at the earliest, but it looks more and more certain that at least some of Apple's future iPhones will ...

DocuSign confirms it's moving to much bigger digs in Seattle high-rise
The months-old rumor is true: DocuSign is moving to the 999 Third Avenue office tower in downtown Seattle. The growing electronic signature company ...

Modern Baseball played Webster w/ Jeff Rosenstock, Sorority Noise & Tiny Moving Parts, covered "Mr. Brightside" ...
photos by Mimi Hong Modern Baseball / Jeff Rosenstock Modern Baseball just wrapped up a tour in their hometown of Philly on Saturday (12/12), ...

Obama: ISIS strategy 'moving forward with a great sense of urgency'
CNN Obama: ISIS strategy 'moving forward with a great sense of urgency' CNN Washington (CNN) The U.S. military battle against ISIS is "moving ...

Resources last updated: 12/15/2015 5:28:31 PM