Slowdown when printing to PDF in a loop
I'm printing a whole bunch of PDFs (multipage feedback reports generated by populating a series of cards with individualised data - mix of text and graphics) and it starts off fast and then inevitably slows down - a lot. While it might start off printing say 14 reports per minute after a few minutes it's down to only 2 or 3. When you're printing 350 reports that obviously takes some time. I'm wondering whether there is something I can try to 'clear the pipes' every few minutes to speed the process up a bit? I've had some success in the past splitting the data up into batches and looping through one batch at a time but it would be great (or at least simpler) not having to do that. Any ideas? I'm on a Mac BTW, so I'm not sure whether this is a cross-platform issue. LC 9.0.5. Terry... ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Possible solution to determine if default network has changed (MacOS only for now)
Beware CARP !! (or, very similarly, HSRP or VRRP). In essence, there are a number of routers, which share a single MAC address - and it is passed between them (so there is always one active router and only it responds to the shared MAC address). Meanwhile they each use their own MAC address to run their routing protocols, and the HSRP. Gives fast, easy and transparent fail-over (but with some pitfalls), so AFAIK not very widely used. Alex. P.S. within Cisco, the engineering name for this was CRAP - but pressure form the marketing guys changed it, initally to CARP, and then to HSRP before it was released. On 22/10/2019 19:05, Bob Sneidar via use-livecode wrote: Hi all. MacOS only for now. I think I put together a way to tell if the default network has changed since the last time an internet connection took place. It's no good of course, just getting the IP address, as given an identical subnet, you have a 1 in 254 change of getting the same IP address on a different network. We want to be absolutely certain. Similarly, the gateway, subnet mask and DNS might also be identical. Finally, the only adapter we care about is the one that is being used as the default route to the internet or local resources. (there may be more than one active adapter, as in the Ethernet and Wireless adapters). The trick is to get the MAC address of the router, then store it and compare it each time you attempt to communicate. Here's what I came up with. Feel free to chide me if I am overthinking this: on mouseUp put "route get default" into tShellCommand put shell(tShellCommand) into tDefaultAdapter put lineOffset("Interface: ", tDefaultAdapter) into tInterfaceLine if tInterfaceLine = 0 then answer info "No default interface found!" as sheet exit mouseUp end if put word 2 of line tInterfaceLine of tDefaultAdapter into tDefaultInterface put "ipconfig getpacket " & tDefaultInterface into tShellCommand put shell(tShellCommand) into tInterfaceDetail put lineOffset("router (ip_mult): ", tInterfaceDetail) into tRouterLine put word 3 of line tRouterLine of tInterfaceDetail into tRouterAddress put char 2 to -2 of tRouterAddress into tRouterAddress put tRouterAddress put "arp " & tRouterAddress into tShellCommand put shell(tShellCommand) into tArpReply put word 4 of tArpReply into tDefaultMACAddress end mouseUp Bob S ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
I still maintain a HC server stack, accessible by clients over a network, of many thousands of cards. Access to any of them using the "find" command is virtually instantaneous. It is LC that starts to visibly slow after about 2000 cards. Someone like Richard or Jacque may know a bit about why that is, but I assume that LC simply carries much more baggage. It must be remembered that HC was designed to run on a 1MB Mac. Color was out of the question, and the routines for finding stuff was considered revolutionary and was carefully guarded. Craig -Original Message- From: Peter Bogdanoff via use-livecode To: How to use LiveCode Cc: Peter Bogdanoff Sent: Tue, Oct 22, 2019 2:40 pm Subject: Re: Push Card Hi Andrew, I think the problem is having very many cards—in the thousands, each with text, images, etc.—that I experience slowdowns. The stack taking a long time to open, save, go to cards, and just wanting to freeze for awhile. When I changed my method to just a few cards with the text and the data used to display it stored in arrays, page loading is lighting fast. Creating fields and buttons, formatting them and filling with text on the fly, then deleting them when I load the next “page" is really fast. I put images on a web server that I pre-download to memory so they display quickly when needed is also part of the plan. These images could otherwise be stored as files on disk, or in a LC stack. Images in a LC stack can be referenced by using a button and setting its icon to ID of the stored image. Using these kinds of techniques I went from a 600 MB collection of stacks down 60 MB— 1/3 text and other data, 1/3 images used as thumbnail images embedded in text fields, and 1/3 the LC engine runtime, and I moved several hundred MB of images to the server. LC is really fast with small stacks, and it’s really convenient just to lay out bunches of cards with stuff, but after awhile, LC just isn’t fast anymore. Peter Bogdanoff artsinteractiveinc.com > On Oct 22, 2019, at 2:01 PM, Andrew Bell via use-livecode > wrote: > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Possible solution to determine if default network has changed (MacOS only for now)
no all I care about is the interface designation which I use in another query later. Bob S > On Oct 22, 2019, at 11:40 , Phil Davis via use-livecode > wrote: > > I'm guessing you meant "route -v get default" ? Otherwise I don't get much > back from the command. > > Phil Davis ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
lol... that may be true...cuz i don't think he'll check the mailing list :) There is only bragging rights at stakeso i just need to add time to his workloadbut not affect the user experience..i am counting on his limited willingness to put hours into it. On Tue, Oct 22, 2019 at 3:02 PM JB via use-livecode < use-livecode@lists.runrev.com> wrote: > And if you tell us what you are going to do > he will never catch on .. .. > > JB > > > On Oct 22, 2019, at 11:57 AM, Tom Glod via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > yeah... the key is to crank up the difficulty and time investment...much > > like decryption...sure...you can decrypt this in a billion years! > > > > On Tue, Oct 22, 2019 at 2:49 PM JJS via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> Everything is crackable. > >> > >> There was once this version of Cubase 5.1 a audio/midi sequencer, very > >> popular among musicians. > >> > >> People from H2O cracked it. It was protected by a USB dongle. > >> > >> They used 1500 manhours for it. And most of the time was not in the > >> program itself, figuring out when it called the dongle, but on how > >> windows handled the dll's to communicate with it. > >> > >> Eventually they wrote their own dll as software-matic dongle. > >> > >> They also said that it was the only version they would crack, because of > >> the many hours they needed to do it. > >> > >> > >> Op 22-10-2019 om 20:27 schreef doc hawk via use-livecode: > >>> On Oct 21, 2019, at 8:02 PM, kee nethery via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > My wife built a Hypercard stack standalone that was protected by a > >> dongle. But, every call to the dongle was something you could search > for in > >> the scripts. So she had scripts that did hashes of the scripts that > talked > >> to the dongle. And she had scripts that did hashes of the scripts that > >> checked the hashes of the scripts … > >>> > >>> “Those who hashed the hasher, have been hashed!” ??? > >>> > >>> Wait, that’s not quite how it goes . . . hmm . . . > >>> ___ > >>> use-livecode mailing list > >>> use-livecode@lists.runrev.com > >>> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >>> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > >> ___ > >> use-livecode mailing list > >> use-livecode@lists.runrev.com > >> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > > > > > > -- > > Tom Glod > > Founder & Developer > > MakeShyft R.D.A (www.makeshyft.com) > > Office:226-706-9339 > > Mobile:226-706-9793 > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Office:226-706-9339 Mobile:226-706-9793 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
And if you tell us what you are going to do he will never catch on .. .. JB > On Oct 22, 2019, at 11:57 AM, Tom Glod via use-livecode > wrote: > > yeah... the key is to crank up the difficulty and time investment...much > like decryption...sure...you can decrypt this in a billion years! > > On Tue, Oct 22, 2019 at 2:49 PM JJS via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> Everything is crackable. >> >> There was once this version of Cubase 5.1 a audio/midi sequencer, very >> popular among musicians. >> >> People from H2O cracked it. It was protected by a USB dongle. >> >> They used 1500 manhours for it. And most of the time was not in the >> program itself, figuring out when it called the dongle, but on how >> windows handled the dll's to communicate with it. >> >> Eventually they wrote their own dll as software-matic dongle. >> >> They also said that it was the only version they would crack, because of >> the many hours they needed to do it. >> >> >> Op 22-10-2019 om 20:27 schreef doc hawk via use-livecode: >>> On Oct 21, 2019, at 8:02 PM, kee nethery via use-livecode < >> use-livecode@lists.runrev.com> wrote: My wife built a Hypercard stack standalone that was protected by a >> dongle. But, every call to the dongle was something you could search for in >> the scripts. So she had scripts that did hashes of the scripts that talked >> to the dongle. And she had scripts that did hashes of the scripts that >> checked the hashes of the scripts … >>> >>> “Those who hashed the hasher, have been hashed!” ??? >>> >>> Wait, that’s not quite how it goes . . . hmm . . . >>> ___ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > -- > Tom Glod > Founder & Developer > MakeShyft R.D.A (www.makeshyft.com) > Office:226-706-9339 > Mobile:226-706-9793 > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
yeah... the key is to crank up the difficulty and time investment...much like decryption...sure...you can decrypt this in a billion years! On Tue, Oct 22, 2019 at 2:49 PM JJS via use-livecode < use-livecode@lists.runrev.com> wrote: > Everything is crackable. > > There was once this version of Cubase 5.1 a audio/midi sequencer, very > popular among musicians. > > People from H2O cracked it. It was protected by a USB dongle. > > They used 1500 manhours for it. And most of the time was not in the > program itself, figuring out when it called the dongle, but on how > windows handled the dll's to communicate with it. > > Eventually they wrote their own dll as software-matic dongle. > > They also said that it was the only version they would crack, because of > the many hours they needed to do it. > > > Op 22-10-2019 om 20:27 schreef doc hawk via use-livecode: > > On Oct 21, 2019, at 8:02 PM, kee nethery via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> My wife built a Hypercard stack standalone that was protected by a > dongle. But, every call to the dongle was something you could search for in > the scripts. So she had scripts that did hashes of the scripts that talked > to the dongle. And she had scripts that did hashes of the scripts that > checked the hashes of the scripts … > > > > “Those who hashed the hasher, have been hashed!” ??? > > > > Wait, that’s not quite how it goes . . . hmm . . . > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Office:226-706-9339 Mobile:226-706-9793 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
Everything is crackable. There was once this version of Cubase 5.1 a audio/midi sequencer, very popular among musicians. People from H2O cracked it. It was protected by a USB dongle. They used 1500 manhours for it. And most of the time was not in the program itself, figuring out when it called the dongle, but on how windows handled the dll's to communicate with it. Eventually they wrote their own dll as software-matic dongle. They also said that it was the only version they would crack, because of the many hours they needed to do it. Op 22-10-2019 om 20:27 schreef doc hawk via use-livecode: On Oct 21, 2019, at 8:02 PM, kee nethery via use-livecode wrote: My wife built a Hypercard stack standalone that was protected by a dongle. But, every call to the dongle was something you could search for in the scripts. So she had scripts that did hashes of the scripts that talked to the dongle. And she had scripts that did hashes of the scripts that checked the hashes of the scripts … “Those who hashed the hasher, have been hashed!” ??? Wait, that’s not quite how it goes . . . hmm . . . ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Possible solution to determine if default network has changed (MacOS only for now)
I'm guessing you meant "route -v get default" ? Otherwise I don't get much back from the command. Phil Davis On 10/22/19 11:05 AM, Bob Sneidar via use-livecode wrote: Hi all. MacOS only for now. I think I put together a way to tell if the default network has changed since the last time an internet connection took place. It's no good of course, just getting the IP address, as given an identical subnet, you have a 1 in 254 change of getting the same IP address on a different network. We want to be absolutely certain. Similarly, the gateway, subnet mask and DNS might also be identical. Finally, the only adapter we care about is the one that is being used as the default route to the internet or local resources. (there may be more than one active adapter, as in the Ethernet and Wireless adapters). The trick is to get the MAC address of the router, then store it and compare it each time you attempt to communicate. Here's what I came up with. Feel free to chide me if I am overthinking this: on mouseUp put "route get default" into tShellCommand put shell(tShellCommand) into tDefaultAdapter put lineOffset("Interface: ", tDefaultAdapter) into tInterfaceLine if tInterfaceLine = 0 then answer info "No default interface found!" as sheet exit mouseUp end if put word 2 of line tInterfaceLine of tDefaultAdapter into tDefaultInterface put "ipconfig getpacket " & tDefaultInterface into tShellCommand put shell(tShellCommand) into tInterfaceDetail put lineOffset("router (ip_mult): ", tInterfaceDetail) into tRouterLine put word 3 of line tRouterLine of tInterfaceDetail into tRouterAddress put char 2 to -2 of tRouterAddress into tRouterAddress put tRouterAddress put "arp " & tRouterAddress into tShellCommand put shell(tShellCommand) into tArpReply put word 4 of tArpReply into tDefaultMACAddress end mouseUp Bob S ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Phil Davis 503-307-4363 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
Hi Andrew, I think the problem is having very many cards—in the thousands, each with text, images, etc.—that I experience slowdowns. The stack taking a long time to open, save, go to cards, and just wanting to freeze for awhile. When I changed my method to just a few cards with the text and the data used to display it stored in arrays, page loading is lighting fast. Creating fields and buttons, formatting them and filling with text on the fly, then deleting them when I load the next “page" is really fast. I put images on a web server that I pre-download to memory so they display quickly when needed is also part of the plan. These images could otherwise be stored as files on disk, or in a LC stack. Images in a LC stack can be referenced by using a button and setting its icon to ID of the stored image. Using these kinds of techniques I went from a 600 MB collection of stacks down 60 MB— 1/3 text and other data, 1/3 images used as thumbnail images embedded in text fields, and 1/3 the LC engine runtime, and I moved several hundred MB of images to the server. LC is really fast with small stacks, and it’s really convenient just to lay out bunches of cards with stuff, but after awhile, LC just isn’t fast anymore. Peter Bogdanoff artsinteractiveinc.com > On Oct 22, 2019, at 2:01 PM, Andrew Bell via use-livecode > wrote: > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Possible solution to determine if default network has changed (MacOS only for now)
> On Oct 22, 2019, at 11:05 , Bob Sneidar via use-livecode > wrote: > > Hi all. > > MacOS only for now. > > I think I put together a way to tell if the default network has changed since > the last time an internet connection took place. It's no good of course, just > getting the IP address, as given an identical subnet, you have a 1 in 254 > change of getting the same IP address on a different network. We want to be > absolutely certain. Well of course, as soon as I posted I realized 2 adapters on the same network like ethernet and wireless would produce the same results, so here's an iteration that gets the MAC address of the default adapter AND the Router's MAC address. Bob S on mouseUp put "route get default" into tShellCommand put shell(tShellCommand) into tDefaultAdapter put lineOffset("Interface: ", tDefaultAdapter) into tInterfaceLine if tInterfaceLine = 0 then answer info "No default interface found!" as sheet exit mouseUp end if put word 2 of line tInterfaceLine of tDefaultAdapter into tDefaultInterface put "ipconfig getpacket " & tDefaultInterface into tShellCommand put shell(tShellCommand) into tInterfaceDetail put lineOffset("chaddr", tInterfaceDetail) into tInterfaceMACLine put word 3 of line tInterfaceMACLine of tInterfaceDetail into tDefaultMACAddress put lineOffset("router (ip_mult): ", tInterfaceDetail) into tRouterLine put word 3 of line tRouterLine of tInterfaceDetail into tRouterAddress put char 2 to -2 of tRouterAddress into tRouterAddress put "arp " & tRouterAddress into tShellCommand put shell(tShellCommand) into tArpReply put word 4 of tArpReply into tDefaultRouterAddress put tDefaultMACAddress & cr & tDefaultRouterAddress into tLastMACs put tLastMACs end mouseUp ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
On Oct 22, 2019, at 8:49 AM, Bob Sneidar via use-livecode wrote: > > I have tried push and pop before but you really have to keep track of the > pushed cards or you end up somewhere unexpected. Every time I’ve tried to use push/pop, it’s been more trouble than it was worth—with the lone exception being a three line sequence of push, do something that absolutely had to use the current card, pop. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
> On Oct 22, 2019, at 11:01 , Andrew Bell via use-livecode > wrote: > > I learned HyperCard in K-12 during the '90s and moved to LiveCode a couple > years ago. My coding efficiency and strategies have developed considerably > over my past couple projects. I don't make a new card for everything, but > easily end up with a dozen cards in a stack for most projects. > > Are you saying that LC is better suited to just throw everything onto 1 card > then turn on&off the visibility of groups/etc.? > > --Andrew Bell Not at all. Hypercard was designed so that people with no database knowedge whatsoever could nevertheless store and search for information quickly and easily by first storing information on "cards", and then having a very robust full text indexing engine (quite advanced for it's time too) so that finding that information would be bearably fast. The trouble came in when people began to discover that at around 2000 cards, things began to slow down, and stacks began to experience corruption. I think they eventually discovered that Hypercard needed time to do some housecleaning, and rapid continuous writes kept it from doing that. LC is optimized (not sure that's the right term for it) to use cards like forms, and then populate those "forms" with data from other sources like databases, arrays, files etc. I have 15 stacks in my current project, and all but the main stack only have one card. I could have simply created 15 cards, but then the size of each card is different, and what each stack does is anything from slightly different to radically different, so having multiple stacks helps me keep all that organized. Also, each stack (I call them modules) can be open simultaneously with others, like the customer stack and the devices stack for example, which I could not do with a single stack and multiple cards. It sounds tempting at first to have groups that get shown and hidden on a single card, but keeping these groups organized, selecting groups under other groups, copying and pasting between groups etc. will quickly cure you of that approach. Bob S ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
On Oct 21, 2019, at 8:02 PM, kee nethery via use-livecode wrote: > > My wife built a Hypercard stack standalone that was protected by a dongle. > But, every call to the dongle was something you could search for in the > scripts. So she had scripts that did hashes of the scripts that talked to the > dongle. And she had scripts that did hashes of the scripts that checked the > hashes of the scripts … “Those who hashed the hasher, have been hashed!” ??? Wait, that’s not quite how it goes . . . hmm . . . ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
I don’t think 12 cards will be an issue. The problem is that cards are a linked list in memory so random access to hundreds of cards can be slow. Next card is always fast (would have to look to see if it is a double link for the same to be true of previous). Thanks, Brian On Oct 22, 2019, 2:02 PM -0400, Andrew Bell via use-livecode , wrote: > I learned HyperCard in K-12 during the '90s and moved to LiveCode a > couple years ago. My coding efficiency and strategies have developed > considerably over my past couple projects. I don't make a new card for > everything, but easily end up with a dozen cards in a stack for most > projects. > > Are you saying that LC is better suited to just throw everything onto > 1 card then turn on&off the visibility of groups/etc.? > > --Andrew Bell > > > > Subject: Re: Push Card > > Message-ID: <2d259a07-7c34-4337-9dbb-24f2ff8e6...@iotecdigital.com> > > Content-Type: text/plain; charset="us-ascii" > > > > I have tried push and pop before but you really have to keep track > > of the pushed cards or you end up somewhere unexpected. I'm still > > not sure what the utility of having lots and lots of cards is, if > > that is what you are doing, especially considering that the LC > > engine is not optimized to use that paradigm. > > > > Bob S > > > > > > > On Oct 22, 2019, at 08:39 , JB via use-livecode > > > wrote: > > > > > > Thank you for the info! > > > > > > I think I am going to rewrite the code to work > > > better and eliminate using push card for this > > > instance. > > > > > > JB > > > > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Possible solution to determine if default network has changed (MacOS only for now)
Hi all. MacOS only for now. I think I put together a way to tell if the default network has changed since the last time an internet connection took place. It's no good of course, just getting the IP address, as given an identical subnet, you have a 1 in 254 change of getting the same IP address on a different network. We want to be absolutely certain. Similarly, the gateway, subnet mask and DNS might also be identical. Finally, the only adapter we care about is the one that is being used as the default route to the internet or local resources. (there may be more than one active adapter, as in the Ethernet and Wireless adapters). The trick is to get the MAC address of the router, then store it and compare it each time you attempt to communicate. Here's what I came up with. Feel free to chide me if I am overthinking this: on mouseUp put "route get default" into tShellCommand put shell(tShellCommand) into tDefaultAdapter put lineOffset("Interface: ", tDefaultAdapter) into tInterfaceLine if tInterfaceLine = 0 then answer info "No default interface found!" as sheet exit mouseUp end if put word 2 of line tInterfaceLine of tDefaultAdapter into tDefaultInterface put "ipconfig getpacket " & tDefaultInterface into tShellCommand put shell(tShellCommand) into tInterfaceDetail put lineOffset("router (ip_mult): ", tInterfaceDetail) into tRouterLine put word 3 of line tRouterLine of tInterfaceDetail into tRouterAddress put char 2 to -2 of tRouterAddress into tRouterAddress put tRouterAddress put "arp " & tRouterAddress into tShellCommand put shell(tShellCommand) into tArpReply put word 4 of tArpReply into tDefaultMACAddress end mouseUp Bob S ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
I learned HyperCard in K-12 during the '90s and moved to LiveCode a couple years ago. My coding efficiency and strategies have developed considerably over my past couple projects. I don't make a new card for everything, but easily end up with a dozen cards in a stack for most projects. Are you saying that LC is better suited to just throw everything onto 1 card then turn on&off the visibility of groups/etc.? --Andrew Bell Subject: Re: Push Card Message-ID: <2d259a07-7c34-4337-9dbb-24f2ff8e6...@iotecdigital.com> Content-Type: text/plain; charset="us-ascii" I have tried push and pop before but you really have to keep track of the pushed cards or you end up somewhere unexpected. I'm still not sure what the utility of having lots and lots of cards is, if that is what you are doing, especially considering that the LC engine is not optimized to use that paradigm. Bob S On Oct 22, 2019, at 08:39 , JB via use-livecode wrote: Thank you for the info! I think I am going to rewrite the code to work better and eliminate using push card for this instance. JB ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
Yeah...He might call me within 24 hours ..laughing ...and that wouldn't surprise me at all. :D Luckily ...none of it is life or death. On Tue, Oct 22, 2019 at 1:44 PM JB via use-livecode < use-livecode@lists.runrev.com> wrote: > Well considering he writes assembly and other languages > and is communicating with other people he might be able > to do things that would surprise you. > > JB > > > On Oct 22, 2019, at 10:38 AM, Tom Glod via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Funny, I just sat down to fire up LC to check on the encryption option. > > That will be the first thing I will do. > > > > My dad will do this using a C++ / assembly debugger, and he finds the > point > > at which the trial limitation is lifted or enforced, and does all his > work > > there. So he'll be looking at memory directly and will try to inject a > > 'simple' workaround. > > > > I'm not sure about this, but probably the arrangement and sequence of > > variables in the applications' memory space will be different each time > it > > starts? I could be wrong but I believe cracks and patches often use a > > specific byte offsets to make changes to specific portions of the > program, > > assuming their location is always the same within the applications > > memory. This is where I think an LC standalone is different, but thats > > just speculation on my part. > > > > With enough time sure...everything can be cracked..., I don't > think > > it will be easy for him at all, given he's never seen LC. > > > > On Tue, Oct 22, 2019 at 11:20 AM J. Landman Gay via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> That was my first thought too, password protecting the stack makes the > >> scripts unreadable. The hacker would have to read the memory directly > and > >> I'm not sure what that would show, but I don't think it would be > >> particularly organized. > >> -- > >> Jacqueline Landman Gay | jac...@hyperactivesw.com > >> HyperActive Software | http://www.hyperactivesw.com > >> On October 22, 2019 10:09:40 AM Bob Sneidar via use-livecode > >> wrote: > >> > >>> I'd be curious to know how well simply pass protecting the stacks does. > >>> Given the "hacker" doesn't know the key that was used for the > >> encryption, > >>> it shouldn't be possible. > >>> > >>> Bob S > >>> > >>> > On Oct 22, 2019, at 07:46 , Tom Glod via use-livecode > wrote: > > JB, of course thats true, its just a matter of how long it takes and > how > skilled the cracker must be. Its definitely not a reason not to try. > > Kee, that sounds like quite the scheme a self-destructing stack. > My > initial instinct is to create some trap using hashing also. > > Thanks. :) > > On Mon, Oct 21, 2019 at 11:03 PM kee nethery via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > My wife built a Hypercard stack standalone that was protected by a > >> dongle. > > But, every call to the dongle was something you could search for in > the > > scripts. So she had scripts that did hashes of the scripts that > talked > >> to > > the dongle. And she had scripts that did hashes of the scripts that > >> checked > > the hashes of the scripts … > > > > Plus, she broke up the calculations into various sections of other > >> code. > > When a script noticed stuff was being altered, it would start erasing > >> stuff > > in the app stack. And it would look for Hypercard itself on their > disk > >> and > > start erasing stuff in it. It would hold on as long as possible doing > >> as > > much damage as possible. > > > > Setting the code to do all this protection was a carefully scripted > > process because one false step and it would self destruct and damage > >> her > > Hypercard. It was pretty obvious to me when that happened because the > > cursing would be rather loud and prolonged. > > > > She’d do things like add up all the chars in a script, do a modulo on > >> that > > number, and then go to script ID to execute a line of > >> code in > > that script. > > > > I’m sure someone could have eventually gotten past all that stuff but > > don’t think anyone ever did. > > > > -- > > > > All that said, shareware authors would routinely hang out on crack > >> sites > > and seconds before releasing their app, they would post a crack. No > one > > wants to be the second person to crack an app so the author would be > >> the > > only crack. That crack would allow someone to use the app for some > >> period > > of time (months) and then it would develop some kind of error. Users > >> would > > call in for support on XYZ error and the answer was, the more recent > > version fixes that. It’s a simple upgrade, here’s the URL for users > >> with > > this error. And those folks would become paid users. > > > > Kee > >>
Re: Push Card
That is nice to know! Actually in my case I went down a path I never should have anyway and writing the code so it works better instead of using recent or push is the way to go. thanks, JB > On Oct 22, 2019, at 10:40 AM, dunbarx--- via use-livecode > wrote: > > This goes back to 1987. The HC team assumed that most people would navigate > like crazy, think rolodex, and being able to retrace ones history would be a > very useful tool. > > There should be a "clear recent" command, so that the piles of cards in that > history can be eliminated. But LC has things that make this simple, the > "recentCards" and "recentNames" properties. > > Craig > > > -Original Message- > From: JB via use-livecode > To: How to use LiveCode > Cc: JB > Sent: Tue, Oct 22, 2019 12:28 pm > Subject: Re: Push Card > > Do you mean to also keep a track of my own card id’s and > then eliminate the ones I do not want in the list? > > That would probably work but I think I will just write the > code differently for this program. It is not a big problem > but the ending up where I did not expect just needs to > be fixed and is not going to be very difficult. > > thanks for the help! > > JB > >> On Oct 22, 2019, at 9:14 AM, Bob Sneidar via use-livecode >> wrote: >> >> One way to do this is to have a single function do the pushing and popping >> so it always knows where it is. >> >> Bob S >> >> >>> On Oct 22, 2019, at 09:04 , JB via use-livecode >>> wrote: >>> >>> I don’t have very many cards but eventually I end >>> up somewhere I didn’t expect and if I cleared the >>> list it would take care of the problem. But if I take >>> the time to write the code better I can solve the >>> problem without using push and pop. >>> >>> JB >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
Well considering he writes assembly and other languages and is communicating with other people he might be able to do things that would surprise you. JB > On Oct 22, 2019, at 10:38 AM, Tom Glod via use-livecode > wrote: > > Funny, I just sat down to fire up LC to check on the encryption option. > That will be the first thing I will do. > > My dad will do this using a C++ / assembly debugger, and he finds the point > at which the trial limitation is lifted or enforced, and does all his work > there. So he'll be looking at memory directly and will try to inject a > 'simple' workaround. > > I'm not sure about this, but probably the arrangement and sequence of > variables in the applications' memory space will be different each time it > starts? I could be wrong but I believe cracks and patches often use a > specific byte offsets to make changes to specific portions of the program, > assuming their location is always the same within the applications > memory. This is where I think an LC standalone is different, but thats > just speculation on my part. > > With enough time sure...everything can be cracked..., I don't think > it will be easy for him at all, given he's never seen LC. > > On Tue, Oct 22, 2019 at 11:20 AM J. Landman Gay via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> That was my first thought too, password protecting the stack makes the >> scripts unreadable. The hacker would have to read the memory directly and >> I'm not sure what that would show, but I don't think it would be >> particularly organized. >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >> On October 22, 2019 10:09:40 AM Bob Sneidar via use-livecode >> wrote: >> >>> I'd be curious to know how well simply pass protecting the stacks does. >>> Given the "hacker" doesn't know the key that was used for the >> encryption, >>> it shouldn't be possible. >>> >>> Bob S >>> >>> On Oct 22, 2019, at 07:46 , Tom Glod via use-livecode wrote: JB, of course thats true, its just a matter of how long it takes and how skilled the cracker must be. Its definitely not a reason not to try. Kee, that sounds like quite the scheme a self-destructing stack. My initial instinct is to create some trap using hashing also. Thanks. :) On Mon, Oct 21, 2019 at 11:03 PM kee nethery via use-livecode < use-livecode@lists.runrev.com> wrote: > My wife built a Hypercard stack standalone that was protected by a >> dongle. > But, every call to the dongle was something you could search for in the > scripts. So she had scripts that did hashes of the scripts that talked >> to > the dongle. And she had scripts that did hashes of the scripts that >> checked > the hashes of the scripts … > > Plus, she broke up the calculations into various sections of other >> code. > When a script noticed stuff was being altered, it would start erasing >> stuff > in the app stack. And it would look for Hypercard itself on their disk >> and > start erasing stuff in it. It would hold on as long as possible doing >> as > much damage as possible. > > Setting the code to do all this protection was a carefully scripted > process because one false step and it would self destruct and damage >> her > Hypercard. It was pretty obvious to me when that happened because the > cursing would be rather loud and prolonged. > > She’d do things like add up all the chars in a script, do a modulo on >> that > number, and then go to script ID to execute a line of >> code in > that script. > > I’m sure someone could have eventually gotten past all that stuff but > don’t think anyone ever did. > > -- > > All that said, shareware authors would routinely hang out on crack >> sites > and seconds before releasing their app, they would post a crack. No one > wants to be the second person to crack an app so the author would be >> the > only crack. That crack would allow someone to use the app for some >> period > of time (months) and then it would develop some kind of error. Users >> would > call in for support on XYZ error and the answer was, the more recent > version fixes that. It’s a simple upgrade, here’s the URL for users >> with > this error. And those folks would become paid users. > > Kee >>> >>> ___ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferenc
Re: Push Card
This goes back to 1987. The HC team assumed that most people would navigate like crazy, think rolodex, and being able to retrace ones history would be a very useful tool. There should be a "clear recent" command, so that the piles of cards in that history can be eliminated. But LC has things that make this simple, the "recentCards" and "recentNames" properties. Craig -Original Message- From: JB via use-livecode To: How to use LiveCode Cc: JB Sent: Tue, Oct 22, 2019 12:28 pm Subject: Re: Push Card Do you mean to also keep a track of my own card id’s and then eliminate the ones I do not want in the list? That would probably work but I think I will just write the code differently for this program. It is not a big problem but the ending up where I did not expect just needs to be fixed and is not going to be very difficult. thanks for the help! JB > On Oct 22, 2019, at 9:14 AM, Bob Sneidar via use-livecode > wrote: > > One way to do this is to have a single function do the pushing and popping so > it always knows where it is. > > Bob S > > >> On Oct 22, 2019, at 09:04 , JB via use-livecode >> wrote: >> >> I don’t have very many cards but eventually I end >> up somewhere I didn’t expect and if I cleared the >> list it would take care of the problem. But if I take >> the time to write the code better I can solve the >> problem without using push and pop. >> >> JB > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
Funny, I just sat down to fire up LC to check on the encryption option. That will be the first thing I will do. My dad will do this using a C++ / assembly debugger, and he finds the point at which the trial limitation is lifted or enforced, and does all his work there. So he'll be looking at memory directly and will try to inject a 'simple' workaround. I'm not sure about this, but probably the arrangement and sequence of variables in the applications' memory space will be different each time it starts? I could be wrong but I believe cracks and patches often use a specific byte offsets to make changes to specific portions of the program, assuming their location is always the same within the applications memory. This is where I think an LC standalone is different, but thats just speculation on my part. With enough time sure...everything can be cracked..., I don't think it will be easy for him at all, given he's never seen LC. On Tue, Oct 22, 2019 at 11:20 AM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > That was my first thought too, password protecting the stack makes the > scripts unreadable. The hacker would have to read the memory directly and > I'm not sure what that would show, but I don't think it would be > particularly organized. > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > On October 22, 2019 10:09:40 AM Bob Sneidar via use-livecode > wrote: > > > I'd be curious to know how well simply pass protecting the stacks does. > > Given the "hacker" doesn't know the key that was used for the > encryption, > > it shouldn't be possible. > > > > Bob S > > > > > >> On Oct 22, 2019, at 07:46 , Tom Glod via use-livecode > >> wrote: > >> > >> JB, of course thats true, its just a matter of how long it takes and how > >> skilled the cracker must be. Its definitely not a reason not to try. > >> > >> Kee, that sounds like quite the scheme a self-destructing stack. My > >> initial instinct is to create some trap using hashing also. > >> > >> Thanks. :) > >> > >> On Mon, Oct 21, 2019 at 11:03 PM kee nethery via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > >> > >>> My wife built a Hypercard stack standalone that was protected by a > dongle. > >>> But, every call to the dongle was something you could search for in the > >>> scripts. So she had scripts that did hashes of the scripts that talked > to > >>> the dongle. And she had scripts that did hashes of the scripts that > checked > >>> the hashes of the scripts … > >>> > >>> Plus, she broke up the calculations into various sections of other > code. > >>> When a script noticed stuff was being altered, it would start erasing > stuff > >>> in the app stack. And it would look for Hypercard itself on their disk > and > >>> start erasing stuff in it. It would hold on as long as possible doing > as > >>> much damage as possible. > >>> > >>> Setting the code to do all this protection was a carefully scripted > >>> process because one false step and it would self destruct and damage > her > >>> Hypercard. It was pretty obvious to me when that happened because the > >>> cursing would be rather loud and prolonged. > >>> > >>> She’d do things like add up all the chars in a script, do a modulo on > that > >>> number, and then go to script ID to execute a line of > code in > >>> that script. > >>> > >>> I’m sure someone could have eventually gotten past all that stuff but > >>> don’t think anyone ever did. > >>> > >>> -- > >>> > >>> All that said, shareware authors would routinely hang out on crack > sites > >>> and seconds before releasing their app, they would post a crack. No one > >>> wants to be the second person to crack an app so the author would be > the > >>> only crack. That crack would allow someone to use the app for some > period > >>> of time (months) and then it would develop some kind of error. Users > would > >>> call in for support on XYZ error and the answer was, the more recent > >>> version fixes that. It’s a simple upgrade, here’s the URL for users > with > >>> this error. And those folks would become paid users. > >>> > >>> Kee > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Office:226-706-9339 Mobile:226-706-9793 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe an
Re: Push Card
Do you mean to also keep a track of my own card id’s and then eliminate the ones I do not want in the list? That would probably work but I think I will just write the code differently for this program. It is not a big problem but the ending up where I did not expect just needs to be fixed and is not going to be very difficult. thanks for the help! JB > On Oct 22, 2019, at 9:14 AM, Bob Sneidar via use-livecode > wrote: > > One way to do this is to have a single function do the pushing and popping so > it always knows where it is. > > Bob S > > >> On Oct 22, 2019, at 09:04 , JB via use-livecode >> wrote: >> >> I don’t have very many cards but eventually I end >> up somewhere I didn’t expect and if I cleared the >> list it would take care of the problem. But if I take >> the time to write the code better I can solve the >> problem without using push and pop. >> >> JB > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
One way to do this is to have a single function do the pushing and popping so it always knows where it is. Bob S > On Oct 22, 2019, at 09:04 , JB via use-livecode > wrote: > > I don’t have very many cards but eventually I end > up somewhere I didn’t expect and if I cleared the > list it would take care of the problem. But if I take > the time to write the code better I can solve the > problem without using push and pop. > > JB ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
I don’t have very many cards but eventually I end up somewhere I didn’t expect and if I cleared the list it would take care of the problem. But if I take the time to write the code better I can solve the problem without using push and pop. JB > On Oct 22, 2019, at 8:49 AM, Bob Sneidar via use-livecode > wrote: > > I have tried push and pop before but you really have to keep track of the > pushed cards or you end up somewhere unexpected. I'm still not sure what the > utility of having lots and lots of cards is, if that is what you are doing, > especially considering that the LC engine is not optimized to use that > paradigm. > > Bob S > > >> On Oct 22, 2019, at 08:39 , JB via use-livecode >> wrote: >> >> Thank you for the info! >> >> I think I am going to rewrite the code to work >> better and eliminate using push card for this >> instance. >> >> JB > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
I have tried push and pop before but you really have to keep track of the pushed cards or you end up somewhere unexpected. I'm still not sure what the utility of having lots and lots of cards is, if that is what you are doing, especially considering that the LC engine is not optimized to use that paradigm. Bob S > On Oct 22, 2019, at 08:39 , JB via use-livecode > wrote: > > Thank you for the info! > > I think I am going to rewrite the code to work > better and eliminate using push card for this > instance. > > JB ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
Thank you for the info! I think I am going to rewrite the code to work better and eliminate using push card for this instance. JB > On Oct 22, 2019, at 3:44 AM, hh via use-livecode > wrote: > >> JB wrote: >> The list of pushed cards is cleared when you quit the application. >> Is there a way to clear the list without quitting the application? > > You could try > > on mouseUp > put "home.livecodescript""e into tA > repeat >pop card into tB >if tB ends with tA then exit repeat > end repeat > end mouseUp > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
That was my first thought too, password protecting the stack makes the scripts unreadable. The hacker would have to read the memory directly and I'm not sure what that would show, but I don't think it would be particularly organized. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On October 22, 2019 10:09:40 AM Bob Sneidar via use-livecode wrote: I'd be curious to know how well simply pass protecting the stacks does. Given the "hacker" doesn't know the key that was used for the encryption, it shouldn't be possible. Bob S On Oct 22, 2019, at 07:46 , Tom Glod via use-livecode wrote: JB, of course thats true, its just a matter of how long it takes and how skilled the cracker must be. Its definitely not a reason not to try. Kee, that sounds like quite the scheme a self-destructing stack. My initial instinct is to create some trap using hashing also. Thanks. :) On Mon, Oct 21, 2019 at 11:03 PM kee nethery via use-livecode < use-livecode@lists.runrev.com> wrote: My wife built a Hypercard stack standalone that was protected by a dongle. But, every call to the dongle was something you could search for in the scripts. So she had scripts that did hashes of the scripts that talked to the dongle. And she had scripts that did hashes of the scripts that checked the hashes of the scripts … Plus, she broke up the calculations into various sections of other code. When a script noticed stuff was being altered, it would start erasing stuff in the app stack. And it would look for Hypercard itself on their disk and start erasing stuff in it. It would hold on as long as possible doing as much damage as possible. Setting the code to do all this protection was a carefully scripted process because one false step and it would self destruct and damage her Hypercard. It was pretty obvious to me when that happened because the cursing would be rather loud and prolonged. She’d do things like add up all the chars in a script, do a modulo on that number, and then go to script ID to execute a line of code in that script. I’m sure someone could have eventually gotten past all that stuff but don’t think anyone ever did. -- All that said, shareware authors would routinely hang out on crack sites and seconds before releasing their app, they would post a crack. No one wants to be the second person to crack an app so the author would be the only crack. That crack would allow someone to use the app for some period of time (months) and then it would develop some kind of error. Users would call in for support on XYZ error and the answer was, the more recent version fixes that. It’s a simple upgrade, here’s the URL for users with this error. And those folks would become paid users. Kee ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
I'd be curious to know how well simply pass protecting the stacks does. Given the "hacker" doesn't know the key that was used for the encryption, it shouldn't be possible. Bob S > On Oct 22, 2019, at 07:46 , Tom Glod via use-livecode > wrote: > > JB, of course thats true, its just a matter of how long it takes and how > skilled the cracker must be. Its definitely not a reason not to try. > > Kee, that sounds like quite the scheme a self-destructing stack. My > initial instinct is to create some trap using hashing also. > > Thanks. :) > > On Mon, Oct 21, 2019 at 11:03 PM kee nethery via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> My wife built a Hypercard stack standalone that was protected by a dongle. >> But, every call to the dongle was something you could search for in the >> scripts. So she had scripts that did hashes of the scripts that talked to >> the dongle. And she had scripts that did hashes of the scripts that checked >> the hashes of the scripts … >> >> Plus, she broke up the calculations into various sections of other code. >> When a script noticed stuff was being altered, it would start erasing stuff >> in the app stack. And it would look for Hypercard itself on their disk and >> start erasing stuff in it. It would hold on as long as possible doing as >> much damage as possible. >> >> Setting the code to do all this protection was a carefully scripted >> process because one false step and it would self destruct and damage her >> Hypercard. It was pretty obvious to me when that happened because the >> cursing would be rather loud and prolonged. >> >> She’d do things like add up all the chars in a script, do a modulo on that >> number, and then go to script ID to execute a line of code in >> that script. >> >> I’m sure someone could have eventually gotten past all that stuff but >> don’t think anyone ever did. >> >> -- >> >> All that said, shareware authors would routinely hang out on crack sites >> and seconds before releasing their app, they would post a crack. No one >> wants to be the second person to crack an app so the author would be the >> only crack. That crack would allow someone to use the app for some period >> of time (months) and then it would develop some kind of error. Users would >> call in for support on XYZ error and the answer was, the more recent >> version fixes that. It’s a simple upgrade, here’s the URL for users with >> this error. And those folks would become paid users. >> >> Kee ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: My old man vs LC Standalone
JB, of course thats true, its just a matter of how long it takes and how skilled the cracker must be. Its definitely not a reason not to try. Kee, that sounds like quite the scheme a self-destructing stack. My initial instinct is to create some trap using hashing also. Thanks. :) On Mon, Oct 21, 2019 at 11:03 PM kee nethery via use-livecode < use-livecode@lists.runrev.com> wrote: > My wife built a Hypercard stack standalone that was protected by a dongle. > But, every call to the dongle was something you could search for in the > scripts. So she had scripts that did hashes of the scripts that talked to > the dongle. And she had scripts that did hashes of the scripts that checked > the hashes of the scripts … > > Plus, she broke up the calculations into various sections of other code. > When a script noticed stuff was being altered, it would start erasing stuff > in the app stack. And it would look for Hypercard itself on their disk and > start erasing stuff in it. It would hold on as long as possible doing as > much damage as possible. > > Setting the code to do all this protection was a carefully scripted > process because one false step and it would self destruct and damage her > Hypercard. It was pretty obvious to me when that happened because the > cursing would be rather loud and prolonged. > > She’d do things like add up all the chars in a script, do a modulo on that > number, and then go to script ID to execute a line of code in > that script. > > I’m sure someone could have eventually gotten past all that stuff but > don’t think anyone ever did. > > -- > > All that said, shareware authors would routinely hang out on crack sites > and seconds before releasing their app, they would post a crack. No one > wants to be the second person to crack an app so the author would be the > only crack. That crack would allow someone to use the app for some period > of time (months) and then it would develop some kind of error. Users would > call in for support on XYZ error and the answer was, the more recent > version fixes that. It’s a simple upgrade, here’s the URL for users with > this error. And those folks would become paid users. > > Kee > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Office:226-706-9339 Mobile:226-706-9793 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Push Card
> JB wrote: > The list of pushed cards is cleared when you quit the application. > Is there a way to clear the list without quitting the application? You could try on mouseUp put "home.livecodescript""e into tA repeat pop card into tB if tB ends with tA then exit repeat end repeat end mouseUp ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode