219 replies to this topic

[MedEvil]

But %SystemRoot%_system32_cmd.exe translates to X:\i386_system32_cmd.exe and that's pure nonsense!



edit:
Also

The element-name entry does not appear unless the current user has changed the properties of the command window.

element-name is a variable representing the entries under the console-window-name subkey. It does not actually appear in the registry. This variable entry displays information that is common to the entries in the console-window-name subkey.

[pscEx]

But %SystemRoot%_system32_cmd.exe translates to X:\i386_system32_cmd.exe and that's pure nonsense!

I think you did not look at that link yet.

The 'pure nonsence' is a REGISTRY KEY NAME!

BTW: This is WORKING code in my trackWBInstall project:

// give the cmd window a history buffer

RegHiveLoad,"WB-Default","%target_sys%\config\default"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","HistoryNoDup","1048576"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","QuickEdit","2048"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","NumberOfHistoryBuffers","5"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","ScreenBufferSize","32768080"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","ScreenColors","15"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","FontSize","786440"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","FontFamily","48"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","FontWeight","400"

RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","HistoryBufferSize","51"

RegHiveUnLoad,"WB-Default"

Peter

[lucho]

Instead HKCU you MUST use HKLM. That is where the hive is mounted to.
Maybe additional: The winbuilder syntax does not accept 0x??? values for RegWrite, and you have convert them to decimal.

Instead of qEmu as emulator you should use VirtualBox. It is freeware, easy to install, much faster and there exist scripts using it.

Peter

Indeed, when I changed HKCU to HKLM, it started to honour it! Then I found out that it honours the "Console" section and not the "Console\%SystemRoot%_system32_cmd.exe" so I removed these. The hex values turned out to work. Finally, the maximum possible number of rows turned out to be 37. I attach the final script; here's the relevant excerpt from it (the screen buffer is set to hold 600 rows):

RegHiveLoad,"WB-default","%TargetDir%\I386\system32\config\default"

RegWrite,HKLM,0x4,"WB-default\Console","ScreenBufferSize",0x2580050

RegWrite,HKLM,0x4,"WB-default\Console","WindowSize",0x250050

RegHiveUnLoad,"WB-default"

Thanks for your help!
Lucho

Attached Files

•  CMD.Script   2.54KB   511 downloads

[MedEvil]

I think you did not look at that link yet.

The 'pure nonsence' is a REGISTRY KEY NAME!

I did take a look and know that it's just a name, but you can't have backslashes in a name!!!
RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","HistoryNoDup","1048576"
means
RegWrite,"HKLM","0x4","WB-Default\Console\X:\i386_system32_cmd.exe","HistoryNoDup","1048576"
So you're creating an extra folder called X: and the key name is i386_system32_cmd.exe!

Correct would be to use for instance:
RegWrite,"HKLM","0x4","WB-Default\Console\Test-Console","HistoryNoDup","1048576"

If a console window is then started simply with cmd, then the values in WB-Default\Console will be used.
But if i start a console window with the name Test-Console then the entries in WB-Default\Console\Test-Console will be used.
I presume that if a certain key is not defined, the one in WB-Default\Console will be used.

[pscEx]

I did take a look and know that it's just a name, but you can't have backslashes in a name!!!
RegWrite,"HKLM","0x4","WB-Default\Console\%SystemRoot%_system32_cmd.exe","HistoryNoDup","1048576"
means
RegWrite,"HKLM","0x4","WB-Default\Console\X:\i386_system32_cmd.exe","HistoryNoDup","1048576"
So you're creating an extra folder called X: and the key name is i386_system32_cmd.exe!

Correct would be to use for instance:
RegWrite,"HKLM","0x4","WB-Default\Console\Test-Console","HistoryNoDup","1048576"

If a console window is then started simply with cmd, then the values in WB-Default\Console will be used.
But if i start a console window with the name Test-Console then the entries in WB-Default\Console\Test-Console will be used.
I presume that if a certain key is not defined, the one in WB-Default\Console will be used.

I also made some tests and I'm not yet sure about the result.
The 'pure nonsence' does not work with cmd.exe as shell. But it is reported at several places for cmd.exe in a PE, and as told, it worked for me, too.

A really working solution for PicoXP (with cmd as shell) is the attached script.
Unfortunatelly that needs WB 076

The disadvantage is that it works for ALL console apps, maybe net etc. But that's only a small disadvantage.

Peter

 CMD.zip   2.15KB   524 downloads

EDIT: I saw, that lucho also posted a working solution.

Sorry, I did not read yet.

[lucho]

A really working solution for PicoXP (with cmd as shell) is the attached script.
Unfortunatelly that needs WB 076

The disadvantage is that it works for ALL console apps, maybe net etc. But that's only a small disadvantage.

Peter

Your solution has a user interface and would thus be more useful in the general case.

By the way, I've compared the action of an antivirus programme under PicoXP and under VistaPE, on the same machine with Vista installed. The difference is that the PicoXP can't access 163 files that the VistaPE can. This is just about 0.2% of the total number of files there, but I wonder why it happens? Perhaps there are changes in the Vista NTFS that make some files inaccessilbe by XP?

Also, PicoXP doesn't seem to work with an USB keyboard and mouse, which fortunately isn't a big problem for me because I use it in unattended mode (without operator intervention)...

Lucho

[pscEx]

Your solution has a user interface and would thus be more useful in the general case.

By the way, I've compared the action of an antivirus programme under PicoXP and under VistaPE, on the same machine with Vista installed. The difference is that the PicoXP can't access 163 files that the VistaPE can. This is just about 0.2% of the total number of files there, but I wonder why it happens? Perhaps there are changes in the Vista NTFS that make some files inaccessilbe by XP?

Also, PicoXP doesn't seem to work with an USB keyboard and mouse, which fortunately isn't a big problem for me because I use it in unattended mode (without operator intervention)...

Lucho

Due to User Interface have a look here

File access: I do not think that it depends on ntfs.

In my opinion it is caused by the fact that picoxp does not contain the core to use GUI based apps.

Add the attached script. It is part of my project trackWBInstall.

I think it will make most of your files accessable which cannot accessed now.

USB mouse/keyboard.
There exists a script adding this functionality. I do currently not remember the name. Search for it.

Peter

 GDI.zip   3.58KB   514 downloads

[lucho]

Due to User Interface have a look here

It's good for those who don't like the default colours.

File access: I do not think that it depends on ntfs.

In my opinion it is caused by the fact that picoxp does not contain the core to use GUI based apps.

Add the attached script. It is part of my project trackWBInstall.

I think it will make most of your files accessable which cannot accessed now.

Thanks but it would add a big number of files, rendering PicoXP to just a "microXP". Why do you think that it depends on the GUI? The (McAfee) antivirus programme in question is a pure console application.

USB mouse/keyboard.
There exists a script adding this functionality. I do currently not remember the name. Search for it.

I did and found this. Do you mean it? I see that it uses slightly different commands. Is this because of WB version difference and can I just replace the old commands with the corresponding new commands? Or do you mean this script? Or both? Does the former depend on the latter or vice-versa or they're independent of one another?

Thanks,
Lucho

[pscEx]

Thanks but it would add a big number of files, rendering PicoXP to just a "microXP". Why do you think that it depends on the GUI? The (McAfee) antivirus programme in question is a pure console application.

Can you check that AV with 'depends' and publish the result here?

Peter

[pscEx]

I did and found this. Do you mean it? I see that it uses slightly different commands. Is this because of WB version difference and can I just replace the old commands with the corresponding new commands? Or do you mean this script? Or both? Does the former depend on the latter or vice-versa or they're independent of one another?

I meant the second one.

IMHO:

• They are independent of each other
• Sorry @Galapo, I did not test your (to make clear: first one) script anywhen.
  If it is preferable here, please contradict!

Peter

[MedEvil]

The first one is only an addon to the second.

The second give USB mouse and keyboard support, but only if they are pluged in right from the start.
The second enables hot plug for Mouse and keyboard. (but might depend on a build with some sort of hwpnp )

[lucho]

Can you check that AV with 'depends' and publish the result here?

Of course. Here is the image file, attached. I closed the window during the virus scan to limit the image file size to an acceptable value (it's too large anyway).

Attached Files

•  scan_dep.zip   638.98KB   514 downloads

[lucho]

The first one is only an addon to the second.

The second give USB mouse and keyboard support, but only if they are pluged in right from the start.
The second enables hot plug for Mouse and keyboard. (but might depend on a build with some sort of hwpnp )

You mean, the first enables hot plug.
I added the second to the "Build" subdirectory of the PicoXP project and it worked instantly (tested with USB flash drive, USB keyboard and USB mouse), adding only less than half a megabyte!

Thanks,
Lucho

[pscEx]

@lucho
@MedEvil,

looks like we are trying to give an Ice-Age project the current real world's features.

@lucho

Maybe you try the nativeEx_barebone poroject, and after download you change it to your needs.
For me, you are able to do it using your own intelligence.
Therfore only what may be difficult to find:
In Basic > !WBManager > DefineFundamentals > click 'Project with command line shell'
In Basic > Shells choose 'CMD' as default shell

Build the project.

If thar runs in emulator, we can tune the build to become smaller, or to include some drivers you need for 'real world'

Peter

[MedEvil]

You mean, the first enables hot plug.

Yes, i do. Had a little slip there.

[Galapo]

The second enables hot plug for Mouse and keyboard. (but might depend on a build with some sort of hwpnp )

No, hwpnp is not necessary.

Regards,
Galapo.

[lucho]

looks like we are trying to give an Ice-Age project the current real world's features.

I don't think that a project that is only 1.5 years old can turn into ice for 1.5 years. It's already doing a good job for me. The bigger window and the USB made it even more useful. 15 MB are still an incredibly small size for what it does. The McAfee console scanner works with it and I don't understand how scanning some 163 of a total of about 7000 files would require a GUI.

Maybe you try the nativeEx_barebone poroject, and after download you change it to your needs.
For me, you are able to do it using your own intelligence.
Therfore only what may be difficult to find:
In Basic > !WBManager > DefineFundamentals > click 'Project with command line shell'
In Basic > Shells choose 'CMD' as default shell

I've tried nativeEx (without the "barebone" suffix) but as far as I can tell, it offers only the "native" API and not the Win32 API. Does the "barebone" version offer the Win32 API? I don't know where to download it because I build the projects on a machine not connected to the Internet and the machine that is connected doesn't run Windows, so I can't download inside WB.

Thanks,
Lucho

P.S. Sorry, I've never programmed for Windows so I may not know some things that may be obvious to you.

[MedEvil]

The McAfee console scanner works with it and I don't understand how scanning some 163 of a total of about 7000 files would require a GUI.

When you can tell us what those 163 files have in common, we might can tell you.

[Brito]

I don't know where to download it because I build the projects on a machine not connected to the Internet and the machine that is connected doesn't run Windows, so I can't download inside WB.

Hello.

There's a good solution, you can install XP inside VirtualBox.

It will allow you to use wb and download any files as necessary, the network connections are automatically made available inside the virtual box.

You can also setup shared folders between the real OS and the virtual machine to copy files from one place to the other.

---------------

I'm working this way with Ubuntu, should be the same for Mac or other modern OS's.

-----------------------------------

In alternative, WinBuilder.exe also runs using WINE. You can run it this way to use the download center.

We didn't tested project building from WINE but at least it should be enough to grab all files that you need and move them back to the windows machine.

[lucho]

When you can tell us what those 163 files have in common, we might can tell you.

Quite difficult, because I have to

1. Make a list of files that couldn't be upened under VistaPE.
2. Make a list of files that couldn't be upened under PicoXP.
3. Sort both lists.
4. Find the files that are in the second list but not the first.
5. Now that I know their names, copy them all and try to find what they have in common, at last.

My observations while watching the scanner work is that tese files are in the "Users" directory hierarchy, so they're much more unlikely to contain malware than those in the system directories. Even if they do, they're not active when the PC is started from the hard disk, so their clean up can be done at that time and a bootable antivirus CD isn't needed for them. Therefore, there's no practical problem that would justify the 5 big steps above and your eventual further analysis.

But I think that the virus scanner scans the files in the same pattern, using always the same system calls, no matter what the type of the file is. Unless it's encrypted or compressed, but these files aren't. The only difference I can think of is that the Vista NTFS is slightly different from the XP NTFS. The Wikipedia article for NTFS says that both XP and Vista use the same version (3.1) of NTFS, but

"Windows Vista introduced Transactional NTFS, NTFS symbolic links, partition shrinking and self-healing functionality though these features owe more to additional functionality of the operating system than the file system itself."

The files in quesiton may be just some of those new types of files.

Regards,
Lucho

[pscEx]

My observations while watching the scanner work is that tese files are in the "Users" directory hierarchy, so they're much more unlikely to contain malware than those in the system directories. Even if they do, they're not active when the PC is started from the hard disk, so their clean up can be done at that time and a bootable antivirus CD isn't needed for them. Therefore, there's no practical problem that would justify the 5 big steps above and your eventual further analysis.

Might be possible that there is some 'misunderstanding' between the nativeEx based PicoXP and your scanner. It is possible that the scanner (some commercial programs still do so!) has a hardcoded 'Documents and Settings' and the names in your PE are different.

On the other hand, may I give you a suggestion:

Our community is rather successfull. And one of the reasons for that is the fact that most of the active members do not have troubles with 'lot and hard work'.

If somebody asks for help, there are two types of askers:

• I want to have the solution RIGHT NOW! I installed WinBuilder, and want to have 'guarantee reactions from this piece of freeware'
• I do what I can, to solve this issue for me and for the other members.

I prefer the second type!

Peter

[MedEvil]

Quite difficult, because I have to

Well, if it's not worth the trouble to you, how can you expect anyone else to invest time into helping you with your problem?

[lucho]

Hello!

Yes, a virtual machine would do the job but I'd prefer to download the nativeEx_barebone as an archive - of course, only if it supports the Win32 API and not only the "native" API.

Well, if it's not worth the trouble to you, how can you expect anyone else to invest time into helping you with your problem?

Sorry I wasn't clear enough. Of course, if it's not worth the trouble for me, it's even less worth the trouble for you. I don't expect you to help me in this case, if I can't help myself or help you help me (sorry it became too complex). But any speculation what can and what cannot be the cause for this is welcome.

Regards,
Lucho

[pscEx]

Hello!

Yes but I'd prefer to download the nativeEx_barebone as an archive - of course, only if it supports the Win32 API and not only the "native" API.

Regards,
Lucho

I think that you misunderstand 'native'

When developing this idea, I used 'native' in the sence of 'native language': Your PE appears to you in your language, not by default in English'

Independent from the project, the WinBuilder always uses standard Win32 DLLs, not only the 'native' NTDLL.DLL.

Peter

[lucho]

Our community is rather successfull. And one of the reasons for that is the fact that most of the active members do not have troubles with 'lot and hard work'.

I can work hard, if needed and if I know that this can help somebody (including myself). In this case, it wouldn't. We have a Bulgarian proverb "work in vain, don't sit in vain" but it shouldn't be considered absolute. The work is not necessarily done just for the sake of the work itself.

If somebody asks for help, there are two types of askers:

• I want to have the solution RIGHT NOW! I installed WinBuilder, and want to have 'guarantee reactions from this piece of freeware'
• I do what I can, to solve this issue for me and for the other members.

I prefer the second type!

If somebody of the first type expects help, it'd be rather silly of him. But hope I'm the second type. You already helped me a lot. Sorry if I didn't do something right. I very often make errors in communication with people when I rely only on typing and reading. Please accept my apologies if I did so again.

Regards,
Lucho