|
Sure - email me so I can give you my paypal. I'll do this for $1500.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
Christian Graus wrote: Sure - email me so I can give you my paypal. I'll do this for $1500.
Ill do it for $1400 and a cookie.
Chocolate chip.
|
|
|
|
|
ROTFL !!!
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
This is probably more of a beginner issue, but Im trying to populate a treeview based off the Northwind Database. The Top level is a list of countries, second level is a list of customers from that country, and 3rd level is supposed to be orderids from that country but it isnt populating. I know its stopping at my 'FillOrderIDs' but I cant seem to figure out why.
I appreciate any advice,
Private Sub FillCountries()
Dim tcountry As String
Dim tnode As TreeNode
Dim tCountryTable As NorthwindDataSet.CountriesDataTable
tCountryTable = Me.CountriesTableAdapter.GetCountriesData
For Each trow As NorthwindDataSet.CountriesRow In tCountryTable
tcountry = trow.Country
tnode = New TreeNode
tnode.Name = "Country"
tnode.Text = tcountry
Me.TreeView1.TopNode.Nodes.Add(tnode)
FillCompanyNames(tcountry, tnode)
Next
End Sub
Private Sub FillCompanyNames(ByVal country As String, ByVal parentnode As TreeNode)
Dim tCompany As String
Dim tnode As TreeNode
Dim CustTable As NorthwindDataSet.CompanyNamesDataTable
CustTable = Me.CompanyNamesTableAdapter.GetCustomersByCountry(country)
For Each trow As NorthwindDataSet.CompanyNamesRow In CustTable
tCompany = trow.CompanyName
tnode = New TreeNode
tnode.Name = "CompanyName"
tnode.Text = trow.CompanyName
tnode.Tag = trow.CompanyName
parentnode.Nodes.Add(tnode)
FillOrderIDs(tCompany, tnode)
Next
End Sub
Private Sub FillOrderIDs(ByVal orderid As String, ByVal parentnode As TreeNode)
Dim tnode As TreeNode
Dim OrdTable As NorthwindDataSet.OrderIdsDataTable
OrdTable = Me.OrderIdsTableAdapter.GetOrderIds(CompanyName)
For Each trow As NorthwindDataSet.OrderIdsRow In OrdTable
tnode = New TreeNode
tnode.Name = "OrderID"
tnode.Text = trow.OrderID
tnode.Tag = trow.OrderID
parentnode.Nodes.Add(tnode)
Next
End Sub
Private Sub btnDisplay_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnDisplay.Click
TreeView1.Nodes.Add("Countries")
FillCountries()
End Sub
|
|
|
|
|
I have compiled a release version of a DLL and installed the .msi on my computer and the DLL resides in C:\Program Files\ etc etc
In another project I have set a reference to the compiled and installed DLL - not to the DLLs in Bin from the DLL project.
Now I am single stepping through a routine in the new project and when I hit the call to the compiled DLL, it brings up a code page from the project for that DLL. Is this normal? How can it happen?
I am very confused about this as surely if I am referencing a DLL in c:\Program Files\etc, how can it be showing me a code page from C:\Work\DasWork\etc etc?
What would happen if I gave this DLL to someone else? What would they see? 
|
|
|
|
|
This is because Visual Studio still knows where the source for the project is.
TheComputerMan wrote: What would happen if I gave this DLL to someone else? What would they see?
Nothing. The debugger would step right over the method calls.
|
|
|
|
|
Thanks Dave. Had me worried for a moment!
|
|
|
|
|
Hi,
your exe file (whether managed or unmanaged, debug or release build) contains the absolute path of your PDB file, and that file contains the absolute paths to all the source files.
So just moving your EXE to another location on the same machine does not hide the internal information; you would have to (re)move the PDB file, or switch to another PC.
|
|
|
|
|
Thanks Luc. It seems strange that it should contain that info.
|
|
|
|
|
You're welcome.
|
|
|
|
|
how make checkbox treeview with vb 6......thank....
24
|
|
|
|
|
Why on earth are you using an unsupported language that is dead, and was useless when it was alive ?
I am sure you can do what you want, but I suspect you'd be looking to buy a third party control to do it. I recommend moving to VB.NET as soon as possible. You'll only be 5 years too late.,
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
|
Hi Gurus,
Here is one that MUST be done the service way...
I'm administering a workgroup in which everybody is an admin, and PCs count is higher than 150!!
I can hear you: How do you survive? Here are the facts...
1- A company in a developing country, which means low resources
(i.e. A domain or any kind of whole-control is NEVER AFFORDABLE)
2- We live on imaging solutions.
3- But that would be too much imaging!! Not really, since we partially
depend on users' will not to lose hours of work, waiting for a restored
PC!!
4- Users MUST be admins, because of many legacy software that WON'T
run restricted. It is no shame to admit this, otherwise, what was Russinovich's
Protection Manager doing, until M$ swallowed him to cover its own embarrassment?
So what do I want?
Windows Updates are essential, and are causing nightmares, specially with
many RCE (Remote Code Execution) vulnerabilities discovered recently.
I need to have my self-update, WSUS replacement service PROTECTED from
being killed. I know how to disable MMC controls, but not a KILL signal.
Is there a way to intercept the kill signal, or disable it for a certain service?
This should be something like the way Terminal Services is run, or otherwise,
like many antivirus software do with their realtime scanners.
(i.e. Either enclosed into an SVCHOST instance, or self-protected by other means)
I heard something about embedding a "required-password" into the assembly
which would eventually cause the KILL signal to fail.
Any help PLEASE?!!
BR,
Khallaf
|
|
|
|
|
M.Khallaf wrote: Is there a way to intercept the kill signal, or disable it for a certain service?
No, there isn't. There is no signal. The process is just stopped and its memory is freed.
M.Khallaf wrote: I heard something about embedding a "required-password" into the assembly
which would eventually cause the KILL signal to fail.
No, there isn't. Like I said, there is no Kill signal, like there is in *NIX.
Since everyone is an admin, you're pretty much screwed. A better solution would have been to make everyone a user and create a security group granting the required permissions to keep the software running.
|
|
|
|
|
Hi Dave Kreskowiak,
Thank you so much for the reply. But you have missed some points in my post:
1- Creation of Security Groups is applicable ONLY in an active directory environment.
2- I'm already an MCSE, come from a networking background, and I use programming for automation and creativity. I'm no part of a programming team, nor a project.
3- Also, to complement the idea, running programs under different credentials can only be achieved using a batch files or tools with which the user MUST have the password for the proposed higher crededntial, or otherwise WILL BE ABLE to read it. It does not make any sense.
Finally, you only answered one part of the question. What I wish is:
1- Have the system answer me "Access is Denied" if I try to kill the process using - for example - Process Explorer; THE SAME WAY IT RESPONDS WHEN YOU TRY KILL "MCSHIELD.EXE" OF MCAFEE OR "RTVSCAN.EXE" OF SYMANTEC. THIS HAPPENS EVEN WHEN YOU ARE USING THE BUILT-IN FULL CONTROL ADMIN ACCOUNT, AND YOU HAVE FULL OWNERSHIP ON THE PROCESS IMAGE (i.e. FILE ON DISK)
or
2- Run the process hidden as a module within an SVCHOST instance like the main instance in windows XP wich runs all of the following:
Windows Audio
Cryptographic Sevices
DHCP Client
Error Reporting Services
COM+ Event System
Help and Support
Network Connections
NLA
System Event Notification
Windows Firewall(ICS)
Distributed Link Tracking Client
Windows Time
Windows Management Instrumentation
Please do not tell me it is not do'able, since I've seen myself a close form of it, though not complete (I've seen a hijacked firefox run as a child to legitimate windows svchost instance, and even that would be one step on the way!)
BR,
Khallaf
modified on Sunday, December 7, 2008 12:14 AM
|
|
|
|
|
M.Khallaf wrote: 1- Creation of Security Groups is applicable ONLY in an active directory environment.
Wanna bet??
M.Khallaf wrote: 2- I'm already an MCSE, come from a networking background, and I use programming for automation and creativity. I'm no part of a programming team, nor a project.
I don't care...
M.Khallaf wrote: 3- Also, to complement the idea, running programs under different credentials can only be achieved using a batch files or tools with which the user MUST have the password for the proposed higher crededntial, or otherwise WILL BE ABLE to read it. It does not make any sense.
You were talking about a service, not an app.
M.Khallaf wrote: 1- Have the system answer me "Access is Denied" if I try to kill the process using - for example - Process Explorer; THE SAME WAY IT RESPONDS WHEN YOU TRY KILL "MCSHIELD.EXE" OF MCAFEE OR "RTVSCAN.EXE" OF SYMANTEC. THIS HAPPENS EVEN WHEN YOU ARE USING THE BUILT-IN FULL CONTROL ADMIN ACCOUNT, AND YOU HAVE FULL OWNERSHIP ON THE PROCESS IMAGE (i.e. FILE ON DISK)
This is only possible if the "process" is running as the System, not a user account. All user account processes can be killed and there's nothing you can do to stop it.
M.Khallaf wrote: 2- Run the process hidden as a module within an SVCHOST instance like the main instance in windows XP wich runs all of the following:
Windows Audio
Cryptographic Sevices
DHCP Client
Error Reporting Services
COM+ Event System
Help and Support
Network Connections
NLA
System Event Notification
Windows Firewall(ICS)
Distributed Link Tracking Client
Windows Time
Windows Management Instrumentation
All of these are non-interactive services. Yes, you can "hyjack" a user-mode but it still doesn't get the full protection your talking about trying to get.
I already told you the only way it works.
As a side, what does all of this have to do with VB.NET??
|
|
|
|
|
It has to do with VB.Net, because I program in VB.Net. Yes, I can still understand examples in C#.Net, but VB.Net is my choice.
Wanna bet?? Smile
Yes, you have ONLY built-in ones.
You were talking about a service, not an app.
You are right about this one, but it does not matter, and you will know why.
This is only possible if the "process" is running as the System, not a user account. All user account processes can be killed and there's nothing you can do to stop it.
This is totally irrelevant. A built-in admin or even an admin member in the built-in admin group has FULL CONTROL on every "breath" that comes in or out of a system. My service runs as Local System and, of course, the built-in admin CAN KILL IT.
You are talking to me as if I was born yesterday. I've been administering netwroks since 2001, and yet I can tell you I had the same illusions about default security permissions and roles of built-in accounts, that were based on the un-realistic "M$ LABS" environment, the days when I was just finished with my MCSE.
All of these are non-interactive services.
Who said that my service is interactive?
Yes, you can "hyjack" a user-mode but it still doesn't get the full protection your talking about trying to get.
I already said that "This is only one step on the way".
You have no clue about the way workgroup security model works in Windows Networks. That I can tell. And yet, you have not answered my questions.
If you don't know the answer, then just quit it, PLEASE!
BR,
Khallaf
|
|
|
|
|
M.Khallaf wrote: You have no clue about the way workgroup security model works in Windows Networks. That I can tell.
No, you can't.
M.Khallaf wrote: es, you have ONLY built-in ones.
Really?? And I supposed the "Debugger Users" group that Visual Studio's installer creates is NOT a security group, even though it specifically gives members elevated permissions to enable the proper functioning of the debugger for those users. Do you want to rethink your answer now??
M.Khallaf wrote: A built-in admin or even an admin member in the built-in admin group has FULL CONTROL on every "breath" that comes in or out of a system.
No, an Admin is NOT God over the entire system. There are restrictions on what an Admin can and cannot do. All you have to do is look in the Local Security Policy tool to figure that out.
M.Khallaf wrote: My service runs as Local System and, of course, the built-in admin CAN KILL IT.
Yeah, you'll note that I never once said that the service has to run under the Local System account. I said the service has to run AS THE SYSTEM. This is a kernel-level account that no user, not even an Admin, can stop. All you have to do to see this is look in Task Manager and look at the account that "System Idle Process" is using.
|
|
|
|
|
OK, I'm in no way into flaming. But, FYI:
Really?? And I supposed the "Debugger Users" group that Visual Studio's installer creates is NOT a security group, even though it specifically gives members elevated permissions to enable the proper functioning of the debugger for those users. Do you want to rethink your answer now??
Another mistake. It is built-in!
No, an Admin is NOT God over the entire system. There are restrictions on what an Admin can and cannot do. All you have to do is look in the Local Security Policy tool to figure that out.
He already has default FC ove it, unless you modify it.
Yeah, you'll note that I never once said that the service has to run under the Local System account. I said the service has to run AS THE SYSTEM. This is a kernel-level account that no user, not even an Admin, can stop. All you have to do to see this is look in Task Manager and look at the account that "System Idle Process" is using.
Another misconception. They are both the same. I only used the TERM more familiar to you as a VS user.
You can't fight a net-admin into his domain. I was only asking for your programming help, but you chose to embarrass yourself.
I advice you to read Russinovich's Microsoft Windows Internals
http://www.amazon.com/gp/product/0735619174/qid=1142840372/sr=1-1/ref=sr_1_1?s=books&v=glance&n=283155
BR,
Khallaf
P.S. I'm on a national holiday, why not give out some net-admin lessons for the deprived
|
|
|
|
|
 Whatever dude...
Oh, BTW. The SVCHOST interface isn't documented for a reason...
|
|
|
|
|
M.Khallaf wrote:
Really?? And I supposed the "Debugger Users" group that Visual Studio's installer creates is NOT a security group, even though it specifically gives members elevated permissions to enable the proper functioning of the debugger for those users. Do you want to rethink your answer now??
Another mistake. It is built-in!
Then how come I don't have it on my local pc?
I don't pretend to know more or even as much as you about this but if it's built-in it should show up right?
|
|
|
|
|
The way this is usually done, is to create a second service, which watches for the first one and restarts it if needed. Of course, this involves you writing the code and I get the impression, despite this being a programming forum, that you're asking an admin question.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
Thank you so much for the concern. I already know about the "coupled-services" trick, and I can write it very easily. I just wanted to know if there was anything special about the way McShield.exe and Rtvscan.exe behave, if someone knew it after all. Orelse, have my service run within the main SVCHOST instance.
Yet, it is not an admin question as much as it is a problem that I want to solve with my VB.Net code. I saw something I liked in an app [or service, for the sake of accuracy ] and I wanted my service to have it. That's all!
BR,
Khallaf
|
|
|
|
|
OK, fair enough. I am pretty sure the coupled services trick is the only way to do that.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
