• Welcome to Valhalla Legends Archive.
 

vb debugger speed

Started by Camel, April 08, 2003, 09:21 PM

Previous topic - Next topic

Skywing

#15
Quote from: Camel on April 09, 2003, 08:57 PM
well actually, i just realized that i dont need to spoof ping at all: DoEvents will make the socket send it's buffer. since 0x25 comes before 0x51, the ping is not affected. sure, it slows down login a little, but who the fuck cares? on my computer (AMD 2100+, 1.73GHz) it takes only about 250ms. imho, that's a small price to pay for 1) bragging rights and 2) not having to explain to all the newbie/idiots how to get bnetauth.dll and where to put it because they were too stupid to extract everything from the zip file...
I'd argue that efficiency is a much better reason for bragging rights :p

If your users don't know where to put things, perhaps you should consider using an installation program so that they don't have to know where stuff is supposed to go.  Windows Installer (MSI) has the advantage of the nice 'repair' option, which basically reinstalls the whole thing without asking the user for their setup informaton again - rather useful if they've managed to delete a dependant library or such.

While you might be right about a slow CheckRevision not impacting the ping time of a single connection, what if you later decide to implement support for multiple connections?  Or even run multiple instances of the same program?  All those wasted CPU cycles do add up - something to think about.

Camel

definately worthy of contemplation, but my bot was designed as an ops bot. i have no reason to support mass loading bots, and 2 or 3 instances of the bot  wont really add up to much because it only takes time during connect--the function is only called once for 0x51

Banana fanna fo fanna

MSI is terrible. If it breaks, everything else breaks with it.

drivehappy

Quote from: St0rm.iD on April 10, 2003, 02:30 PM
MSI is terrible. If it breaks, everything else breaks with it.
That made no sense. If the installer is corrupted then, yes, it wouldn't work.

Yoni

Actually, St0rm is right.

Try to annoy MS Office 2000. Then you'll see the fury of MSI unleashed.

TheMinistered

#20
He could always use machine code and still have the advantages of an independent package with a _little_ less overhead than a full visual basic implementation perhaps?

Skywing

Quote from: TheMinistered on April 10, 2003, 10:27 PM
He could always use machine code and still have the advantages of an independent package with a _little_ less overhead than a full visual basic implementation perhaps?
And how exactly do you plan on doing this with VB?  Using CallWindowProc, something which is not guaranteed to work and likely to break on future platforms?

Skywing

Quote from: Yoni on April 10, 2003, 10:27 PM
Actually, St0rm is right.

Try to annoy MS Office 2000. Then you'll see the fury of MSI unleashed.
MS Office 2000's screwed itself up many times for me, but I've seen countless damaged Office installs and never seen one which took the rest of MSI with it.

drivehappy

Quote from: Yoni on April 10, 2003, 10:27 PM
Actually, St0rm is right.

Try to annoy MS Office 2000. Then you'll see the fury of MSI unleashed.

If MSI is that messed up, turn it off through MMC.

Banana fanna fo fanna


Skywing

#25
Quote from: St0rm.iD on April 11, 2003, 05:40 PM
HOW!!?!?!@^#$^(!?

From Windows 2000 Help (this took about 5 seconds to find via the index):
QuoteManaging options for computers through Group Policy
Windows Installer can be configured using Group Policy and Active Directory to manage the computer installation options.

The following table shows policies concerned with managing the Group Policy computer options for Windows Installer. To configure these policies, start Group Policy as described in Start the Group Policy snap-in. Next, in the console tree, click the Windows Installer node.

Where?

applicable policy name
Computer Configuration
Administrative Templates
Windows Installer
Policy Details
Disable Windows Installer Disables or restricts the use of Windows Installer.
This policy can prevent users from installing software on their system or permit users to install only those programs offered by an administrator.

If you enable this policy, you can use the options in the Disable Windows Installer box to establish an installation policy.

Never
Windows Installer is fully enabled. Users can install and upgrade software. Windows Installer is enabled by default in Windows 2000.
For non-managed apps only
Users can install only those programs that an administrator assigns (offers on the desktop) or publishes (adds to Add/Remove programs).
Always
Windows Installer is disabled.
Note

This policy affects Windows Installer only. It does not prevent users from using other methods to install and upgrade programs.

Always install with elevated privileges Windows Installer uses system permissions when it installs any program on the system.
This policy extends to all programs the elevated privileges usually reserved for programs that have been assigned to the user (offered on the desktop) or the computer (installed automatically), or made available in Add/Remove Programs in Control Panel. This policy lets users install programs that require access to directories that the user might not have permission to view or change, including directories on highly restricted computers.

If you disable this policy, or do not configure it, the system applies the current user's permissions when it installs programs that are not distributed or offered by an administrator.

Note

This policy appears both in the Computer Configuration and User Configuration folders. To make this policy effective, you must enable the policy in both folders.

Disable browse dialog box for new source Prevents users from searching for installation files when adding features or components to an installed program.
This policy disables the Browse button beside the Use feature from list in the Windows Installer dialog box. As a result, users must select an installation file source from the Use features from list configured by the administrator.

This policy applies even when the installation is running in the user's security context.

If you disable this policy or do not configure it, the Browse button is enabled when an installation is running in the user's security context, but only administrators can browse when an installation is running with elevated system privileges, such as installations offered on the desktop or in Add/Remove Programs.

This policy affects Windows Installer only. It does not prevent users from using other browsers, such Windows Explorer or My Network Places, to search for installation files.

Disable patching Prevents users from installing patches to upgrade their programs.
Patches are updates or upgrades that replace only those program files that have changed. Because patches can be easy vehicles for malicious programs, some installations prohibit their use.

This policy applies only to installations that run in the user's security context. By default, users who are not administrators cannot apply patches to installations that run with elevated system privileges, such as those offered on the desktop or in Add/Remove Programs.

Disable IE security prompt for Windows Installer scripts Allows Web-based programs to install software on the computer without notifying the user.
By default, when a script hosted by an Internet browser attempts to install a program on the system, the system warns the user and allows him or her to select or refuse the installation. This policy suppresses the warning and allows the installation to proceed.

This policy is designed for enterprises that use Web-based tools to distribute programs to their employees. However, because it might pose a security risk, it should be applied cautiously.

Enable user control over installs Permits users to change installation options that typically are available only to administrators.

This policy bypasses some of the security features of Windows Installer. It permits installations to complete that otherwise would be halted due to a security violation.

The security features of Windows Installer prevent users from changing installation options that are typically reserved for administrators, such as specifying the directory to which files are installed. If Windows Installer detects that an installation package has permitted the user to change a protected option, it stops the installation and displays an error message. These security features operate only when the installation program is running in a privileged security context in which it has access to directories that are denied to the user.

This policy is designed for less restrictive environments. It can be used to circumvent errors in an installation program that prevent software from being installed.

Logging
Enter one or more of the following installation log mode options:

[w][e][a][r][c][m][p][v]

  • Specifies the types of events that Windows Installer records in its transaction log for each installation. The log, Msi.log, appears in the Temp directory of the system volume.
    When you enable this policy, you can specify the types of events you want Windows Installer to record. To indicate that an event type is recorded, enter the letter representing the event type. You can enter the letters in any order and list as many or as few event types as you want. To disable logging, delete all of the letters from the box.

    The Windows Installer logging options are as follows:

    Mode Log entry
    i Status messages
    w Non-fatal warnings
    e All error messages
    a Startup of actions
    r Action-specific records
    u User requests
    c Initial user interface parameters
    m Out-of-memory
    p Terminal properties
    v Verbose output
    o Out of disk space messages

    Notes

    If you disable this policy, or do not configure it, Windows Installer logs the default event types, represented by the letters iweap.
    You can include all possible events in the installation log file by entering iwearucmpvo. However, doing so will add considerable time to the installation process.
But real hackers don't ever read the documentation, right, $t0rm? ;)

TheMinistered

There is another method other than using CallWindowProc which works.

Skywing

Quote from: TheMinistered on April 11, 2003, 06:15 PM
There is another method other than using CallWindowProc which works.
Feel free to elaborate on it, then, especially if you're suggesting people use machine code from VB!

Banana fanna fo fanna

Thank you kindly.
BTW, I never used the windows help, thanx.

Skywing

Quote from: St0rm.iD on April 11, 2003, 06:34 PM
Thank you kindly.
BTW, I never used the windows help, thanx.
As I finished explaining to Yoni, it's actually got some useful information you probably didn't know - enough that he decided to re-add it to his Start menu, anyway :p

|