Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

Problems moving from 2005r? to 2007r3 (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Profile.txt is not a CSV?
Next thread: FolderItem.GetSaveInfo questions


Reading *CSV Files versus *.Txt Files   -   Claude Stone
  Problems moving from 2005r? to 2007r3   -   David Glass
   Re: Problems moving from 2005r? to 2007r3   -   Tim Jones
   Re: Problems moving from 2005r? to 2007r3   -   David Glass
   Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
   Re: Problems moving from 2005r? to 2007r3   -   David Glass
   Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
    RE: Problems moving from 2005r? to 2007r3   -   Rog
     Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
      RE: Problems moving from 2005r? to 2007r3   -   Rog
       Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
        RE: Problems moving from 2005r? to 2007r3   -   Rog
         Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
       Re: Problems moving from 2005r? to 2007r3   -   Giovanni
       Re: Problems moving from 2005r? to 2007r3   -   Giovanni
        EXE and DLL files   -   Thomas Tempelmann
   Re: Problems moving from 2005r? to 2007r3   -   Mark O'Neill
   Re: Problems moving from 2005r? to 2007r3   -   Mark O'Neill
    Re: Problems moving from 2005r? to 2007r3   -   Thomas Tempelmann
     Re: Problems moving from 2005r? to 2007r3   -   Nick Lockwood
     Re: Problems moving from 2005r? to 2007r3   -   Mark O'Neill
     Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
   Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy
   Re: Problems moving from 2005r? to 2007r3   -   Mark O'Neill
   Re: Problems moving from 2005r? to 2007r3   -   Norman Palardy

Problems moving from 2005r? to 2007r3
Date: 23.11.08 18:47 (Sun, 23 Nov 2008 09:47:14 -0800)
From: David Glass
Greetings,

I'm trying to move a project from 5r? to 7r3, and when I do a 'Check
Project for Errors' it seems to get almost to the end, and then fail
with:

Internal Error: Assertion Failed
Error reporter failed to locate source of error

Which is followed by:
Internal error.
An unhandled NilObjectException exception has occurred.
....

The status bar at the bottom of the IDE window reports 'Check failed
with 2 errors', but obviously (based on the first message) doesn't
tell me where the two errors are.

Invariably, this occurs after I've done a lot of other error fixing,
as I do some refactoring, and have fixed all the other errors
reported, and am expecting a 'clean bill of health' as it were.

Thoughts?

Am I going to have to comment out the entire project and slowly start
uncommenting things?

Re: Problems moving from 2005r? to 2007r3
Date: 23.11.08 18:54 (Sun, 23 Nov 2008 10:54:46 -0700)
From: Tim Jones
On Nov 23, 2008, at 10:47 AM, David Glass wrote:

> Greetings,
>
> I'm trying to move a project from 5r? to 7r3, and when I do a
> 'Check Project for Errors' it seems to get almost to the end, and
> then fail with:

I'd recommend either 7r1 or 7r5. I no longer have 7r3 handy, but I
skipped it for various nasty reasons (which is also why I didn't keep
it).

Also, why not move up to 8r4.2? It's the best version since 5.5.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 23.11.08 20:19 (Sun, 23 Nov 2008 11:19:26 -0800)
From: David Glass
7r3 is stable for me, and r4 and r5 didn't 'do' anything really
compelling so I've stayed on r3.

I've avoided 8rX because of the change in the build process, and while
this project is OS X only, I didn't really want to be working in two
versions of Rb (one for OS X only apps, and one for multi-platform
apps).

At any rate, 8r4 allowed me to resolve all the errors so I'm a happy
camper at this point.

On Nov 23, 2008, at 9:54 AM, Tim Jones wrote:

> On Nov 23, 2008, at 10:47 AM, David Glass wrote:
>
>> Greetings,
>>
>> I'm trying to move a project from 5r? to 7r3, and when I do a
>> 'Check Project for Errors' it seems to get almost to the end, and
>> then fail with:
>
> I'd recommend either 7r1 or 7r5. I no longer have 7r3 handy, but I
> skipped it for various nasty reasons (which is also why I didn't
> keep it).
>
> Also, why not move up to 8r4.2? It's the best version since 5.5.
>
> Tim

Re: Problems moving from 2005r? to 2007r3
Date: 23.11.08 23:08 (Sun, 23 Nov 2008 15:08:25 -0700)
From: Norman Palardy

On 23-Nov-08, at 12:19 PM, David Glass wrote:

> 7r3 is stable for me, and r4 and r5 didn't 'do' anything really
> compelling so I've stayed on r3.
>
> I've avoided 8rX because of the change in the build process, and
> while this project is OS X only, I didn't really want to be working
> in two versions of Rb (one for OS X only apps, and one for multi-
> platform apps).
>
> At any rate, 8r4 allowed me to resolve all the errors so I'm a happy
> camper at this point.

The changes to the build process and how it built Windows apps is one
reason TO move to a newer version

<http://ramblings.aaronballman.com/2008/05/important_win32_application_pa.html
>

If you ever have people reporting odd crashes the single file exe may
actually be the source of the problem

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 23.11.08 23:37 (Sun, 23 Nov 2008 14:37:13 -0800)
From: David Glass
I don't, so at this point it isn't compelling.

On Nov 23, 2008, at 2:08 PM, Norman Palardy wrote:

>
> If you ever have people reporting odd crashes the single file exe
> may actually be the source of the problem
>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 00:18 (Sun, 23 Nov 2008 16:18:26 -0700)
From: Norman Palardy

On 23-Nov-08, at 3:37 PM, David Glass wrote:

> I don't, so at this point it isn't compelling.

The whole point with the issue with the single file exe's is you never
knew if/when it might break
Any OS patch or update might break your app

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Problems moving from 2005r? to 2007r3
Date: 24.11.08 01:20 (Sun, 23 Nov 2008 16:20:15 -0800)
From: Rog
Norman:
The "whole point" as you say, is that you broke our app(s) with your "fix".

R. Greene
Telios Systems

> -----Original Message-----
> From: <email address removed>
> [mailto:<email address removed>] On
> Behalf Of Norman Palardy
> Sent: Sunday, November 23, 2008 3:18 PM
> To: REALbasic NUG
> Subject: Re: Problems moving from 2005r? to 2007r3
>
> On 23-Nov-08, at 3:37 PM, David Glass wrote:
>
> > I don't, so at this point it isn't compelling.
>
> The whole point with the issue with the single file exe's is
> you never
> knew if/when it might break
> Any OS patch or update might break your app
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 01:44 (Sun, 23 Nov 2008 17:44:27 -0700)
From: Norman Palardy

On 23-Nov-08, at 5:20 PM, Rog wrote:

> Norman:
> The "whole point" as you say, is that you broke our app(s) with your
> "fix".
>
> R. Greene
> Telios Systems

They aren't broken. They build differently.
But they wont break with OS updates like they could have (and we do
have bug reports with cases like this)

Yes, it's not as easy to deploy a single exe. Zip the file and send
that out. Or make a self-extracting zip file and send that.
Or do like MS recommends and use an installer so Windows treats it
like a first class citizen and it can be properly installed and
uninstalled.
Users expect these things on Windows.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Problems moving from 2005r? to 2007r3
Date: 24.11.08 04:47 (Sun, 23 Nov 2008 19:47:04 -0800)
From: Rog

A typical installation of our code has about 70 exe programs and about 25
users.

If I told them that they had to use an installer, for every user, every time
we fixed a bug or made a change in one of those programs, I would most
likely get registered mail from their attorney.

We have a method of updating those users -- one that is real-time,
dependable, reliable, and invisible --
one that has most definitely been broken by the "fix".

And as far as Microsoft is concerned, the whole ideal of dll's is to share
common routines, not generate 70 sub-folders that contain virtually idential
library files.

I know there are issues with dll's, what has been called "dll hell". But,
surely, there could be some sort of version control on the library files
that would allow them to be shared and co-exist with earlier versions -- in
the same directory as the programs or in the system32 folder. That would be
a performance improvement, save space and might even be considered "first
class".

R. Greene
Telios SYstems

> -----Original Message-----
> From: <email address removed>
> [mailto:<email address removed>] On
> Behalf Of Norman Palardy
> Sent: Sunday, November 23, 2008 4:44 PM
> To: REALbasic NUG
> Subject: Re: Problems moving from 2005r? to 2007r3
>
> On 23-Nov-08, at 5:20 PM, Rog wrote:
>
> > Norman:
> > The "whole point" as you say, is that you broke our app(s)
> with your
> > "fix".
> >
> > R. Greene
> > Telios Systems
>
> They aren't broken. They build differently.
> But they wont break with OS updates like they could have (and we do
> have bug reports with cases like this)
>
> Yes, it's not as easy to deploy a single exe. Zip the file and send
> that out. Or make a self-extracting zip file and send that.
> Or do like MS recommends and use an installer so Windows treats it
> like a first class citizen and it can be properly installed and
> uninstalled.
> Users expect these things on Windows.
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 08:18 (Mon, 24 Nov 2008 00:18:00 -0700)
From: Norman Palardy

On 23-Nov-08, at 8:47 PM, Rog wrote:

>
> A typical installation of our code has about 70 exe programs and
> about 25
> users.
>
> If I told them that they had to use an installer, for every user,
> every time
> we fixed a bug or made a change in one of those programs, I would most
> likely get registered mail from their attorney.

You can do auto updates for each program. It's not that much harder
than updating a single file exe. A bit more but still quite achievable.
Or use an installer that only installs the new components.
Installer Vise can do this. I'm sure others can as well.

> We have a method of updating those users -- one that is real-time,
> dependable, reliable, and invisible --
> one that has most definitely been broken by the "fix".

Does it not handle the sub directories where the dll's are ?
That can be done.

> And as far as Microsoft is concerned, the whole ideal of dll's is to
> share
> common routines, not generate 70 sub-folders that contain virtually
> idential
> library files.

Do you use the exact same versions of RB and plugins for every program
100% of the time ?
And recompile every program every time any RB or plugin version
changes ?
If you do then yes you may have several copies of dll's.

But if you do not then you have several different versions of what
look externally to be "the same" dll's (but they're not)
And trying to put them all in the same directory would result in "DLL
hell" where some apps load the wrong version of the DLL.

> I know there are issues with dll's, what has been called "dll hell".
> But,
> surely, there could be some sort of version control on the library
> files
> that would allow them to be shared and co-exist with earlier
> versions -- in
> the same directory as the programs or in the system32 folder. That
> would be
> a performance improvement, save space and might even be considered
> "first
> class".

Putting everything in System32 can cause DLL hell (and MS recommends
you NOT do it)
Say App 1 needs version 1 of a DLL and App 2 need version 2 of the
same DLL with the same file name like ... winsock.dll - my fave :)
Install App 2 then App 1 and you've ruined app 2 as the wrong DLL is
installed but has the exact same file name.
And it's quite possible that installing app 2 wrecks app 1.

This is why MS recommends each app have it own directory and put DLL's
next to it and the default search path for DLL's generally starts with
the directory holding the application. MS recommends that to help
developers and end users avoid DLL hell and improve their overall
experience.

It can cause DLL hell when developers try to put many applications in
the same directory with all the dlls in that directory.
You'd have to update all applications when any of them changes as you
may have new dll's for just one of them.
So RB builds with the dll's in a subdirectory so you can put many
exe's in the same directory and each has it's own dlls that it will
load from it's own dll location. But that can cause duplication of
DLL's.

No matter what, there's someone going to be affected by how the
applications are built.
Single file exe's break for some people under weird circumstances that
we have no control over. And they can break suddenly and inexplicably
with OS patches and updates.
Putting all the dll's in one directory breaks apps if they dont use
the same version of RB and all plugins to build them.
And putting the DLL's in a subdirectory causes duplication BUT is
generally safe in every other operational respect. It uses more disk
space.
The OS is smart enough to not reload the DLL if it is the exact same
one (MS has an entire OS loader team that write this stuff)

Those are the things that were considered when making this change
Reread Aaron's blog about it. <http://ramblings.aaronballman.com/2008/05/important_win32_application_pa.html
>
It was not done willy nilly nor without considering that it would
impact people.
But, this makes it so your applications will be more stable and not
experience the unusual crashes we did see reported from single file
exe's.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Problems moving from 2005r? to 2007r3
Date: 24.11.08 22:41 (Mon, 24 Nov 2008 13:41:34 -0800)
From: Rog
> -----Original Message-----
> From: <email address removed>
> [mailto:<email address removed>] On
> Behalf Of Norman Palardy
> Sent: Sunday, November 23, 2008 11:18 PM
> To: REALbasic NUG
> Subject: Re: Problems moving from 2005r? to 2007r3
<snip>
> Putting everything in System32 can cause DLL hell (and MS recommends
> you NOT do it)
> Say App 1 needs version 1 of a DLL and App 2 need version 2 of the
> same DLL with the same file name like ... winsock.dll - my fave :)
> Install App 2 then App 1 and you've ruined app 2 as the wrong DLL is
> installed but has the exact same file name.
> And it's quite possible that installing app 2 wrecks app 1.

What I was suggesting was to change the NAME of the dll for different
versions which would eliminate any incompatibility.
So with your example WINSOCK.dll would be WINSOCKv1.dll or WINSOCKv2.dll.

All the programs compiled with WINSOCKv1 would use WINSOCKv1.
All the programs compiled with WINSOCKv2 would use WINSOCKv2.
WINSOCKv1 and WINSOCKv2 could then co-exist in the same directory -- one
copy of each available to all the programs that use them.

It would seem to me that the dll's internal to RB could easily be tied to
the RB release version.
Maybe I am missing something, but why would this not work?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 23:35 (Mon, 24 Nov 2008 15:35:20 -0700)
From: Norman Palardy

On 24-Nov-08, at 2:41 PM, Rog wrote:

>> -----Original Message-----
>> From: <email address removed>
>> [mailto:<email address removed>] On
>> Behalf Of Norman Palardy
>> Sent: Sunday, November 23, 2008 11:18 PM
>> To: REALbasic NUG
>> Subject: Re: Problems moving from 2005r? to 2007r3
> <snip>
>>
>> Putting everything in System32 can cause DLL hell (and MS recommends
>> you NOT do it)
>> Say App 1 needs version 1 of a DLL and App 2 need version 2 of the
>> same DLL with the same file name like ... winsock.dll - my fave :)
>> Install App 2 then App 1 and you've ruined app 2 as the wrong DLL is
>> installed but has the exact same file name.
>> And it's quite possible that installing app 2 wrecks app 1.
>
> What I was suggesting was to change the NAME of the dll for different
> versions which would eliminate any incompatibility.
> So with your example WINSOCK.dll would be WINSOCKv1.dll or
> WINSOCKv2.dll

That would be something that plugin authors would need to do
RB really does very little with the DLL's provided by vendors as part
of how it builds an application

> All the programs compiled with WINSOCKv1 would use WINSOCKv1.
> All the programs compiled with WINSOCKv2 would use WINSOCKv2.
> WINSOCKv1 and WINSOCKv2 could then co-exist in the same directory --
> one
> copy of each available to all the programs that use them.
>
> It would seem to me that the dll's internal to RB could easily be
> tied to the RB release version.
> Maybe I am missing something, but why would this not work?

If I build App A, RB names the dll's accordingly - winsock.dll since
in that app its only used once
Then I build App B, and again RB names the dll's accordingly -
winsock.dll since in that app I only use it once

Now I put them in one common directory and ... which is which ?

And if a plugin author did not version their plugins how would RB do
it ?
They'd all be version 1 (which has happened before)

The current set up allows it to be correct regardless of how many
versions you have on disk as the DLL loader for the OS actually
figures out if they are / are not the same dll and only loads one copy
in to memory regardless of how many versions you have on disk.

Now there are some things I can imagine that would help reduce disk
space usage BUT they don't alter this behavior that the OS DLL loader
has




_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 08:59 (Sun, 23 Nov 2008 23:59:52 -0800)
From: Giovanni
Wow is this making it's rounds again?

It seems that every few months we go through this topic. hint: do a
search on the list BEFORE posting.

Giovanni
•••••••••••••••••
Sent from iphone...dx...

On Nov 23, 2008, at 11:18 PM, Norman Palardy <<email address removed>
> wrote:

>
> On 23-Nov-08, at 8:47 PM, Rog wrote:
>
>>
>> A typical installation of our code has about 70 exe programs and
>> about 25
>> users.
>>
>> If I told them that they had to use an installer, for every user,
>> every time
>> we fixed a bug or made a change in one of those programs, I would
>> most
>> likely get registered mail from their attorney.
>
> You can do auto updates for each program. It's not that much harder
> than updating a single file exe. A bit more but still quite
> achievable.
> Or use an installer that only installs the new components.
> Installer Vise can do this. I'm sure others can as well.
>
>> We have a method of updating those users -- one that is real-time,
>> dependable, reliable, and invisible --
>> one that has most definitely been broken by the "fix".
>
> Does it not handle the sub directories where the dll's are ?
> That can be done.
>
>> And as far as Microsoft is concerned, the whole ideal of dll's is
>> to share
>> common routines, not generate 70 sub-folders that contain virtually
>> idential
>> library files.
>
> Do you use the exact same versions of RB and plugins for every
> program 100% of the time ?
> And recompile every program every time any RB or plugin version
> changes ?
> If you do then yes you may have several copies of dll's.
>
> But if you do not then you have several different versions of what
> look externally to be "the same" dll's (but they're not)
> And trying to put them all in the same directory would result in
> "DLL hell" where some apps load the wrong version of the DLL.
>
>> I know there are issues with dll's, what has been called "dll
>> hell". But,
>> surely, there could be some sort of version control on the library
>> files
>> that would allow them to be shared and co-exist with earlier
>> versions -- in
>> the same directory as the programs or in the system32 folder. That
>> would be
>> a performance improvement, save space and might even be considered
>> "first
>> class".
>
> Putting everything in System32 can cause DLL hell (and MS recommends
> you NOT do it)
> Say App 1 needs version 1 of a DLL and App 2 need version 2 of the
> same DLL with the same file name like ... winsock.dll - my fave :)
> Install App 2 then App 1 and you've ruined app 2 as the wrong DLL is
> installed but has the exact same file name.
> And it's quite possible that installing app 2 wrecks app 1.
>
> This is why MS recommends each app have it own directory and put
> DLL's next to it and the default search path for DLL's generally
> starts with the directory holding the application. MS recommends
> that to help developers and end users avoid DLL hell and improve
> their overall experience.
>
> It can cause DLL hell when developers try to put many applications
> in the same directory with all the dlls in that directory.
> You'd have to update all applications when any of them changes as
> you may have new dll's for just one of them.
> So RB builds with the dll's in a subdirectory so you can put many
> exe's in the same directory and each has it's own dlls that it will
> load from it's own dll location. But that can cause duplication of
> DLL's.
>
> No matter what, there's someone going to be affected by how the
> applications are built.
> Single file exe's break for some people under weird circumstances
> that we have no control over. And they can break suddenly and
> inexplicably with OS patches and updates.
> Putting all the dll's in one directory breaks apps if they dont use
> the same version of RB and all plugins to build them.
> And putting the DLL's in a subdirectory causes duplication BUT is
> generally safe in every other operational respect. It uses more disk
> space.
> The OS is smart enough to not reload the DLL if it is the exact same
> one (MS has an entire OS loader team that write this stuff)
>
> Those are the things that were considered when making this change
> Reread Aaron's blog about it. <http://ramblings.aaronballman.com/2008/05/important_win32_application_pa.html
> >
> It was not done willy nilly nor without considering that it would
> impact people.
> But, this makes it so your applications will be more stable and not
> experience the unusual crashes we did see reported from single file
> exe's.
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 09:19 (Mon, 24 Nov 2008 00:19:36 -0800)
From: Giovanni
totally agree...

there are applications that need child EXE or utils that need to exist.

I believe that this fix as cost RS some clients in one way or another.
Having a single EXE for some of our projects have been the main reason
to use RS, now we use something else for some projects. If you are
going to have DLL's and if your applications will be bloat ware, why
not use .Net?

Ok, that last one was a low blow. But honestly, how hard is it for RS
to give use an OPTION to create an unsupported single EXE?

I mean, I would even pay for it just to have that option.

Why not listen to US the customer, we want a SINGLE EXE even if it
kills us.

Have an annoying splash or prompt telling me "What your about to do is
a RS-SIN! If you proceed your on your own". I am big enough to handle
it!

This is a Chili subject but come on.

We want what we had! Give me my single EXE option!!!

On Nov 23, 2008, at 7:47 PM, Rog wrote:

>
> A typical installation of our code has about 70 exe programs and
> about 25
> users.
>
> If I told them that they had to use an installer, for every user,
> every time
> we fixed a bug or made a change in one of those programs, I would most
> likely get registered mail from their attorney.
>
> We have a method of updating those users -- one that is real-time,
> dependable, reliable, and invisible --
> one that has most definitely been broken by the "fix".
>
> And as far as Microsoft is concerned, the whole ideal of dll's is to
> share
> common routines, not generate 70 sub-folders that contain virtually
> idential
> library files.
>
> I know there are issues with dll's, what has been called "dll hell".
> But,
> surely, there could be some sort of version control on the library
> files
> that would allow them to be shared and co-exist with earlier
> versions -- in
> the same directory as the programs or in the system32 folder. That
> would be
> a performance improvement, save space and might even be considered
> "first
> class".
>
> R. Greene
> Telios SYstems
>
>> -----Original Message-----
>> From: <email address removed>
>> [mailto:<email address removed>] On
>> Behalf Of Norman Palardy
>> Sent: Sunday, November 23, 2008 4:44 PM
>> To: REALbasic NUG
>> Subject: Re: Problems moving from 2005r? to 2007r3
>>
>> On 23-Nov-08, at 5:20 PM, Rog wrote:
>>
>>> Norman:
>>> The "whole point" as you say, is that you broke our app(s)
>> with your
>>> "fix".
>>>
>>> R. Greene
>>> Telios Systems
>>
>> They aren't broken. They build differently.
>> But they wont break with OS updates like they could have (and we do
>> have bug reports with cases like this)
>>
>> Yes, it's not as easy to deploy a single exe. Zip the file and send
>> that out. Or make a self-extracting zip file and send that.
>> Or do like MS recommends and use an installer so Windows treats it
>> like a first class citizen and it can be properly installed and
>> uninstalled.
>> Users expect these things on Windows.
>>
>> _______________________________________________
>> Unsubscribe or switch delivery mode:
>> <http://www.realsoftware.com/support/listmanager/>
>>
>> Search the archives:
>> <http://support.realsoftware.com/listarchives/lists.html>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 10:37 (Mon, 24 Nov 2008 09:37:46 +0000)
From: Mark O'Neill

On 23 Nov 2008, at 19:19, David Glass wrote:

> At any rate, 8r4 allowed me to resolve all the errors so I'm a happy
> camper at this point.

I still can't get past the Menu problem I was experiencing before, so
I'm staying with RB2007r4 for the time being as I don't like the
thought of recreating my menu from scratch again.

All the best,

Mark.
------------------------------------------------------------
RB Class
"Killer Tool Bar" - theme-based x-platform toolbar
www.rbclass.com




_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 11:13 (Mon, 24 Nov 2008 10:13:36 +0000)
From: Mark O'Neill
Hi Norman,

On 23 Nov 2008, at 22:08, Norman Palardy wrote:

> The changes to the build process and how it built Windows apps is
> one reason TO move to a newer version
>
> <http://ramblings.aaronballman.com/2008/05/important_win32_application_pa.html
> >

So, if I understand that correctly, if I don't use any plugins - which
I'm not aware that I do as my entire app is written with nothing more
than custom canvas based controls - my app won't need to generate any
dlls, and therefore won't have the Trojan problem even if I compile
from RB2007r4?

All the best,

Mark.
------------------------------------------------------------
RB Class
"Killer Tool Bar" - theme-based x-platform toolbar
www.rbclass.com


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 11:26 (Mon, 24 Nov 2008 11:26:09 +0100)
From: Thomas Tempelmann
On 24.11.2008 11:13 Uhr, "Mark O'Neill" <<email address removed>> wrote:

> So, if I understand that correctly, if I don't use any plugins

Then you still might be having DLLs. Some of RB's internal functions are
implemented as plugins internally.

To check, download the latest RB version, run it in demo mode and see what
it puts into the output file/folder when you run your projects in the
debugger.


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 14:05 (Mon, 24 Nov 2008 13:05:28 +0000)
From: Nick Lockwood
Actually I think RS could do a lot to make this complaint go away by
simply changing their internal plugins to use static linking.

I've basically stopped using 3rd party plugins as a result of this
change because I prefer a single exe output, and I'm happy to make
that compromise, but I still occasionally get burned by using a
seemingly innocuous internal function such as MD5 or Base64 encoding
only to find that it uses a plugin.

There's no point asking for the option for single exe exports back -
we won't get it because RS don't want REALbasic to get a reputation
for producing broken applications (RB apps already get enough grief
because they're bloated and have non-standard UI).

What we *could* ask for is RS to include a decent installer maker as
part of the IDE - one which checks for installed DLLs and doesn't
overwrite them with the wrong version, or duplicate them
unnecessarily. Good installer makers are expensive and unfamiliar to
Mac users. RS should treat this as just another platform-specific
issue to be smoothed over with a simple interface that doesn't require
any platform-specific knowledge.

Nick

On 24 Nov 2008, at 10:26, Thomas Tempelmann wrote:

> On 24.11.2008 11:13 Uhr, "Mark O'Neill" <<email address removed>> wrote:
>
>> So, if I understand that correctly, if I don't use any plugins
>
> Then you still might be having DLLs. Some of RB's internal functions
> are
> implemented as plugins internally.
>
> To check, download the latest RB version, run it in demo mode and
> see what
> it puts into the output file/folder when you run your projects in the
> debugger.
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 16:06 (Mon, 24 Nov 2008 15:06:12 +0000)
From: Mark O'Neill
Hi Thomas,

On 24 Nov 2008, at 10:26, Thomas Tempelmann wrote:

> To check, download the latest RB version, run it in demo mode and
> see what
> it puts into the output file/folder when you run your projects in the
> debugger.

I would if I could get it to compile without telling me that my menu
item doesn't exist! lol

All the best,

Mark.
------------------------------------------------------------
RB Class
"Killer Tool Bar" - theme-based x-platform toolbar
www.rbclass.com




_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 17:35 (Mon, 24 Nov 2008 09:35:47 -0700)
From: Norman Palardy

On 24-Nov-08, at 6:05 AM, Nick Lockwood wrote:

> Actually I think RS could do a lot to make this complaint go away by
> simply changing their internal plugins to use static linking.
>
> I've basically stopped using 3rd party plugins as a result of this
> change because I prefer a single exe output, and I'm happy to make
> that compromise, but I still occasionally get burned by using a
> seemingly innocuous internal function such as MD5 or Base64 encoding
> only to find that it uses a plugin.
>
> There's no point asking for the option for single exe exports back -
> we won't get it because RS don't want REALbasic to get a reputation
> for producing broken applications (RB apps already get enough grief
> because they're bloated and have non-standard UI).
>
> What we *could* ask for is RS to include a decent installer maker
> as part of the IDE - one which checks for installed DLLs and doesn't
> overwrite them with the wrong version, or duplicate them
> unnecessarily. Good installer makers are expensive and unfamiliar to
> Mac users. RS should treat this as just another platform-specific
> issue to be smoothed over with a simple interface that doesn't
> require any platform-specific knowledge.
>
> Nick

This makes a lot of sense

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 17:30 (Mon, 24 Nov 2008 09:30:55 -0700)
From: Norman Palardy

On 24-Nov-08, at 3:13 AM, Mark O'Neill wrote:

> Hi Norman,
>
> On 23 Nov 2008, at 22:08, Norman Palardy wrote:
>
>> The changes to the build process and how it built Windows apps is
>> one reason TO move to a newer version
>>
>> <http://ramblings.aaronballman.com/2008/05/important_win32_application_pa.html
>> >
> So, if I understand that correctly, if I don't use any plugins -
> which I'm not aware that I do as my entire app is written with
> nothing more than custom canvas based controls - my app won't need
> to generate any dlls, and therefore won't have the Trojan problem
> even if I compile from RB2007r4?

2007r4 does not use the new compile process so it won't matter
It still generates the EXE with DLL's being loaded from memory which
_could_ suffer from the issue where a new OS patch breaks it

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 19:17 (Mon, 24 Nov 2008 18:17:52 +0000)
From: Mark O'Neill
Hi Norman,

On 24 Nov 2008, at 16:30, Norman Palardy wrote:

>> So, if I understand that correctly, if I don't use any plugins -
>> which I'm not aware that I do as my entire app is written with
>> nothing more than custom canvas based controls - my app won't need
>> to generate any dlls, and therefore won't have the Trojan problem
>> even if I compile from RB2007r4?
>
> 2007r4 does not use the new compile process so it won't matter
> It still generates the EXE with DLL's being loaded from memory which
> _could_ suffer from the issue where a new OS patch breaks it

I was actually asking whether it would still suffer from the Trojan
problem - i.e., Anti-Virus software looking at an RB compiled app and
thinking it's got a Trojan in it... If I don't use plugins - and hence
hopefully not have any DLLs, will it be "Trojan Safe" in RB2007r4?

All the best,

Mark.
------------------------------------------------------------
RB Class
"Killer Tool Bar" - theme-based x-platform toolbar
www.rbclass.com




_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Problems moving from 2005r? to 2007r3
Date: 24.11.08 20:54 (Mon, 24 Nov 2008 12:54:04 -0700)
From: Norman Palardy

On 24-Nov-08, at 11:17 AM, Mark O'Neill wrote:

> Hi Norman,
>
> On 24 Nov 2008, at 16:30, Norman Palardy wrote:
>
>>> So, if I understand that correctly, if I don't use any plugins -
>>> which I'm not aware that I do as my entire app is written with
>>> nothing more than custom canvas based controls - my app won't need
>>> to generate any dlls, and therefore won't have the Trojan problem
>>> even if I compile from RB2007r4?
>>
>> 2007r4 does not use the new compile process so it won't matter
>> It still generates the EXE with DLL's being loaded from memory
>> which _could_ suffer from the issue where a new OS patch breaks it
>
> I was actually asking whether it would still suffer from the Trojan
> problem - i.e., Anti-Virus software looking at an RB compiled app
> and thinking it's got a Trojan in it... If I don't use plugins - and
> hence hopefully not have any DLLs, will it be "Trojan Safe" in
> RB2007r4?

That is entirely up to the virus detection software makers making sure
they correctly identify things

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>