Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

Ostatnie posty - Strona 691

  Forum

TheEmu
Dołączył: Jul 2012
7424 post(y/ów)

Moving iStripper data to a new location

Wszystko o iStripper
September 18, 2020, 35 odpowiedzi
No @Hansachs they are not entirely different - I have ***** from helpful "knowledgable" users at both ends of the scale. In one case one such user changed the value of an environment variable (actually a VMS Logical Name) that provided the location of just such a directory. It "worked" in that it did what he wanted, in the short term, but caused that same user problems later when he used some other feature of the program that relied on the relationship between that directory and others. This is an exact equivalent to the case of changing the registry entry pointing to a directory.

No matter how "knowledgeable" we are we can not know if

1) There is some part of the program that has used knowledge of where the data directory is either directly by hard coding some or all of its name or uses knowledge of the relative paths between the data directory and some other directory such as the vghd or vghd/bin directories. I very much doubt that there are any such usages, but we do not know that there are none. (One possibility is in some old, little used part of the program that may only get used for debugging purposes)

2) That the meaning, or even the existence, of the registry entry will not change with a future release or that some feature introduces the situation described in the previous paragraph.

3) We do not know if it is "safe" to change the directory to some arbitrary name. For example the software may use a fixed size buffer somewhere to hold the data directory name. What happens if the user provides an a very long path name that causes the buffer to overflow?

4) We do not know if it is safe to change the directory name while the program is running. Perhaps different parts of the software handle it in different ways. For example one part may read the directory path from the registry during program initialisation and from then on use that value until the program exits but some other part reads it only when some particular function is first used and some other part re-reads it every time some other function is used. This would lead to different parts of the program using different locations for the data directory. Given that the program now seems to use rather more threads than it did previously such behaviour could well have been introduced quite recently.

The last could be particularly problematic if a naive user was following instructions even if they are told to exit the program before editing the registry. It has been quite obvious from previous posts that many user are not aware that closing the GUI does not quit the program even if there are no visible signs of it on the desktop.

Now, I do not think that any of these are particularly likely for the particular case under discussion, but we simply do not know.

Having spent far too much of my working life sorting out problems such as the above (and I have seen case similar to all of those that I have outlined) I am very disappointed when others suggest that doing such things, no matter how simple or obviously "correct" they are, are not a problem. They all too often have unforseen, and sometimes expensive, side effects that in the worst case only show up intermitently several months later.
HansSachs
Dołączył: Mar 2016
2851 post(y/ów)

Moving iStripper data to a new location

Wszystko o iStripper
September 18, 2020, 35 odpowiedzi
We currently think we know what the registry entry in question is used for, and we are probably right. But we do not truely know it, and we certainly do not know how it may be used in the future.
For example, Totem could decide to split the Data folder into separate parts each with its own folder and each pointed to by a separate registry entry - perhaps Cards, Scenes, MiscData and Temp.
It's also an eventuality which could happen, a chasm hole to open in the ground while we are walking in our city and eat us... but the risk is so low that we usually can walk outside without not even thinking about it.
Same about registry changes we are talking about. Anyway, even in such an improbable case, a simple deletion of the changed value and a new installation could easily solve the issue.

Consider a hypothetical program that is identical to iStripper in every way except that the protection against using cards copied from another user is controlled by a registry entry that comprises a 128 bit key made up by concatenating the user id with an encryption key and that by replacing the encryption key part with one copied from a different user would allow you to play copies of that user's cards. Now this is a very weak protection scheme but the fact that it can be overcome by exactly the same mechanism as that used to change the data path does not mean that it would be, in your own words, "intended by the design of the application to be available and used when needed."
Such an extreme case is totally different from the sort of registry changes this thread is about, since the speculated inserted code copied from another user's one would mean acquiring and using stolen and false informations. Which would be, of course, a totally different matter from what an ordinary change of a registry value is.
celine
EKIPA
Dołączył: Sep 2007
8103 post(y/ów)

UPDATED! Please read - Thank God It's -crazy- Friday

Wszystko o iStripper
September 18, 2020, 0 odpowiedzi
Thank God It's Friday and the start of a crazy crazy week!

First, a quick sum up of last week releases:

  • On your desktop you have welcomed:
Fanfan in high black boots that make her bottom even rounder, Clara Rene, wet in her tiny tiny denim shorts, shy Miluniel in white lace, Irina & Celia Clay in black lace, Jade in red lace, and our little masterpiece Eve Sweet in a torrid openwork dress....



  • And on your mobile, we have released:
Eve Sweet in her Horny Heist erotic parody, even more impressive on mobile, the EXCEPTIONAL duo Jia + Lia in bikini and Bad Barbie playing with your nerves and her tiny student skirt...




Attention! Huge event: CRAZY WEEK - Season 3!

From September 18 to September 25, enjoy our most appreciated promotions! These offers have been put in duo to make sure all of you can all participate, even if you already own all the shows available:

  • from September 18, 11.00 am Paris time to September 21 11.00 am Paris time:
Scratch Card & Progressive Packs
--> IMPORTANT : RE-OPENED till Sept. 22, 11.00 am!!! <--

  • from September 21, 11.00 am Paris time to September 22 11.00 am paris time:
Mystery Envelopes & Free packs

  • from September 22, 11.00 am Paris time to September 25 09.00 am Paris time:
Slot machine with JOKER & Redraw!


AND THAT'S NOT ALL!!

A measuring tape appears at left on all the promo pages : the more credits you invest in the promos, the more the centimeters raise till you reach the very new Special Event Card featuring Cara Mell, waiting to become your personal assistant!



(note: this Special event card of Cara Mell cannot be won in the scratch games but only thru the mesureing tape)

AND THAT'S NOT ALL!!

The 20% reload bonus is ON for the whole period!


Happy Crazy week !
TheEmu
Dołączył: Jul 2012
7424 post(y/ów)

Moving iStripper data to a new location

Wszystko o iStripper
September 18, 2020, 35 odpowiedzi
I have ***** far too many times from "knowledgable" users of software packages giving such advice that I have learnt the hard way that it is never advisable to encourage naive to do even the simplest of such things without making it clear that at the very least they are using an unofficial mechanism to achieve what they want to do and that there can be no guarantees about it continuing to work. To this end calling it a hack is one part of making that clear.

We currently think we know what the registry entry in question is used for, and we are probably right. But we do not truely know it, and we certainly do not know how it may be used in the future.

For example, Totem could decide to split the Data folder into separate parts each with its own folder and each pointed to by a separate registry entry - perhaps Cards, Scenes, MiscData and Temp. If users are modifying the current registry entry then if Totem want to introduce such a change they have the choice either to break the program for those users who have made use of the old "knowledge" or to involve themselves in extra work to accommodate them.

As a more realistic example, albeit at a lower level, I have ***** from a knowledgeable user (actually a co-developer) who knew that a particular list was implemented as a linked list and rather than use the published API function to navigate from one element to the next used that knowledge to do it himself (despite vigorous objections at the time but "management" allowed him to do so for reasons of "efficiency" and "convenience"). This had two effects

1) We could not later change the implementation to a more efficient one
2) Everything fell to pieces when the system was moved to a multiprocessor

If Instead of all these values being in the registry,
and they were in a Configuration File in the Data folder,
Would you still call it hacking if Instructed to
Use Notepad, Open the configuration file and edit the Path?

If the instructions to use the registry editor or a text editor were in the user manual (or provided in some other similar way) then neither would be a hack. If that information is only passed by a "knowledgable" person (even by someone on the actual development team) then it would still be a hack.
readyforanything
Dołączył: Apr 2011
5037 post(y/ów)