jdoe

Your GetComputerName function is not really a good use of this API but anyway, using this single code line below to get computer name, runs 3 times faster than the API. Dim sComputerName as String sComputerName = Environ$("COMPUTERNAME")

Are you using DAO recordset ? If so, after adding data, you need to update the recordset and then close it. If you don't update, the new data will be lost. The end of Access table edits should look like this... rst.Update rst.Close set rst = Nothing

Does anyone know where the sfc_os.dll file with no registry check went? It is not possible to download it any more Thanks <{POST_SNAPBACK}> There it is... SFC_OS.DL_

Sorry evilvoice but I can't find a 64bits executable disassembler. I didn't thought it was hard to find. If someone knows one, post a link to it.

Zip and post the Windows XP x64 version of SFC_OS.DLL and I will post back the offset and hex values.

You can move your 30 files to a temp folder, do what you what in the folder you're working on and then move back your 30 files to the original folder. But you'll have to type the 30 files name.

The switch order seem to be important... winzip32.exe /noqp /notip /autoinstall Look this link for more info WinZip installation switch

With VB you can do this with DAO or ADO and execute an SQL command. SELECT * FROM Table WHERE ...bla bla bla Search for Access database and you'll get full of sample code using DAO.

With CDIMAGE.EXE and CDBURN.EXE this can be done. Create an ISO with CDIMAGE.EXE (download here at MSFN) and then burn it with CDBURN.EXE (download the Windows 2003 Resource Kit) You can find all the swithes needed for CDIMAGE with the search button of MSFN. For CDBURN search MSFN or GOOGLE. If you're really stuck, post what you have done in your batch and more help will come. But first... Try (there's nothing better for learning).

WinINSTALL LE (free) can do that. It's the only way I know of doing it but I'm sure there's more program for that.

Sorry to have not been very clear on this one

If you pass a file name as a parameter of a batch file then you can get the file size with this command... IF %~z1 EQU 0 GOTO Zero Type FOR /? at command prompt to know all informations you can retreive from %~ Hoping this help

When you double-click a .VBS file, the default program started is WSCRIPT.EXE If you want this script to run in a dos window, start your script with CSCRIPT.EXE This way, wscript.echo will display what you want without waiting for user input. CSCRIPT.EXE file.vbs That's it

Search Google with these two words. You're gonna get what you want VBScript FileSystemObject

Try this

Using the default VB6 library you can do it like that... Kill "C:\Program Files\Folder\test.txt" FileCopy "C:\Program Files\documents\test.txt", "C:\Program Files\Folder\test.txt" It's not the perfect code but it work (with an error handler). To prevent an error with Kill you can remove the read-only attribute with SetAttr before calling Kill. And it's not a good idea to have hard coded path like that (use variable instead).

You can do this with a VBScript easily. With a FileSystemObject you can add lines in ASCII or Unicode text file. 1) Open the file you want to edit 2) Create a temp file 3) Read you source file line by line 4) Add those lines in your temp file 5) When your text is found - InStr(FileLine,Text) - add the extra lines you want 6) When source file is all red then close it and delete it 7) Rename temp file as source file and that's it I can provide you sample code but if you're not familiar with VBScript, I don't think it will help.

@prathapml I don't really understand what's the big deal about a variable name (%SHORTPF%). It's JUST a variable name after all. I provide many batches samples in MSFN forum and seeing SiMoNsAyS using some of them is proving me that they are not useless. Go ahead Simon, use it all if you need them. I think that it was not the best post of prathapml.

Yeah, that's what I thought. But it could have been... SET CURRENTPATH=%CD% FOR Bla Bla Bla CD %CURRENTPATH% Nevermind

If somebody create a universal program for command-line switch installer then the Application Switches forum would be useless, but it's not for tomorrow And for seeing that before, that's for sure. I have made a batch like this for testing purpose. It a solution having the advantage to easily adding programs by adding a folder and a CMD Personnally I would remove the POPD (useless) command and replace the PUSHD command by CD /D. And the ECHO command would be more at the right place in the program CMD, but it's my point of view Reinventing the weel is not an easy task Sorry Afterdawn, I was feeling like this today.

There's no need to copy paste ShellExecute API in all forms of your project. Remove it from your forms and create a new module or copy it in modShellWait.bas and replace Private by Public. Option Explicit Public Const SW_SHOWNORM = 1 Public Const SW_SHOWMIN = 2 Public Const SW_SHOWMAX = 3 Public Declare Function ShellExecute Lib "shell32.dll" _ Alias "ShellExecuteA" (ByVal hWnd As Long, _ ByVal lpOperation As String, ByVal lpFile As String, _ ByVal lpParameters As String, _ ByVal lpDirectory As String, _ ByVal nShowCmd As Long) As Long But you will get the same wait problem. ShellExecute don't wait for command to terminate before executing next code line (but it seem to not be a problem on your project).

The problem with Shell command in VB6 is that it don't wait before the launched program exit before executing next code line. There's a piece of code that you can use as a ShellWait command. I'm not sure but I think if you put MSVBVM60.DLL in the same directory as your APP.EXE then your program will work even if the runtime is not include with the OS (need to be confirm). modShellWait.bas Private Const INFINITE = &HFFFF Private Const SYNCHRONIZE = &H100000 Private Declare Sub WaitForSingleObject Lib "kernel32.dll" _ (ByVal hHandle As Long, ByVal dwMilliseconds As Long) Private Declare Function OpenProcess Lib "kernel32.dll" _ (ByVal dwDA As Long, ByVal bIH As Integer, ByVal dwPID As Long) As Long Private Declare Sub CloseHandle Lib "kernel32.dll" (ByVal hObject As Long) Public Sub RunCmd(CmdPath As String, _ Optional WindowStyle As VbAppWinStyle = vbNormalFocus) Dim hProcess As Long On Error GoTo Err_RunCmd hProcess = OpenProcess(SYNCHRONIZE, 0, Shell(CmdPath, WindowStyle)) If hProcess Then WaitForSingleObject hProcess, INFINITE CloseHandle hProcess End If Exit Sub Err_RunCmd: Err.Clear End Sub Syntax -------- RunCmd "setup.exe /s /noreboot /example", vbHide vbHide - Hide your app execution The default vbNormalFocus - Your program is visible and have focus An other solution is to use WScript.Shell object Dim WSS As Object Set WSS = WScript.CreateObject("WScript.Shell") WSS.Run "setup.exe /s /noreboot /example", 1, True Hoping this help

I use UPX for PE for a while now and I agree with prathapml and RyanVM. For getting SFX smaller or few EXE's it's very great but I would not recommand using it on every DLL or EXE. Performance are getting weak and it can be very significant when you need speed or repeating call of a program. Last point, the -force switch is not a good idea. If the EXE or DLL is not recognize as good by UPX then it's not a good idea to force UPX to compress it. The result can lead to a not working program. Conclusion... if you don't have problem with disk spaces, don't use it.

HIVEDEF.INF is not fully reliable to set default settings because the XP setup overwrite many of them. BTW, I made a batch for that few weeks ago. It change reg settings for all users (even already existing account). REGWIDE

I thought we couldn't put spaces in label name. I'm not sure how your INF work but if you pass %1 argument somewhere, then you can get what you want with %~n1 (extract only last name of path) Type FOR /? at command prompt for more details.